Hi

I'm recieving the following error when generating usiong the Adapter template targeting CF 2.0.

The type 'System.ComponentModel.BrowsableAttribute' exists in both 'c:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll' and 'c:\Program Files\Solutions Design\LLBLGen Pro v2.0\RuntimeLibraries\DotNet20\SD.LLBLGen.Pro.ORMSupportClasses.CF20.dll'

C:\Project\ORM\Adapter\CF\AdapterCF\DatabaseGeneric\EntityClasses\ArrangementEntity.cs

Has anyone encountered such an error?

If so is there how can the conflict be resolved?

C

Hi Yarm, if possible, provide more info (http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=9076) Is the first time this happen? Is there a pattern you have observed?

You've referenced the compact framework orm support classes dll . Please reference the .NET 20 version of that dll

First question - Is not the 'SD.LLBLGen.Pro.ORMSupportClasses.CF20.dll' a version 2 dll?

I regenerated the two adapter projects from scratch and get the same error.

I'm targetiing the CF.NET 2.0 in the LLBLgen tool.

Lastly I added and removed the folowing dlls from the following directories: C:\Program Files\Solutions Design\LLBLGen Pro v2.0\RuntimeLibraries\DotNET20\SD.LLBLGen.Pro.ORMSupportClasses.CF20.dll

C:\Program Files\Solutions Design\LLBLGen Pro v2.0\RuntimeLibraries\DotNET20\SD.LLBLGen.Pro.DQE.SqlServerCe.CF20.dll

When I reference the .NET 20 dlls as sugested I get a different set of errors. Namely:

The type or namespace name 'ISerializable' could not be found (are you missing a using directive or an assembly reference?)

Code attached.

Actually too big a file...

The system.dll I have of the CF.NET 2.0 SDK doesn't contain a browsable attribute in that namespace.

Could you check if the system/mscorlib referenced in your generated code are indeed of the CF.NET SDK and not the default .NET assemblies?

Isn't System.dll general to .Net? I wasn't aware that that the CF.Net SDK had its own version.

Anyway the System.dll is sourced from C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll

So yes it is the default assembly.

I have the CF SDK but it does not include a System.dll.

I'm using version 3 of the SQLServer CE. The SDK is installed using the SSCE31SDK-ENU.msi installer from MS.

Is there a specialised System.dll?

C

Referencing the follwing dll gives the same error.

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll

cjarman66 wrote:

Isn't System.dll general to .Net? I wasn't aware that that the CF.Net SDK had its own version.

Anyway the System.dll is sourced from C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll

So yes it is the default assembly.

I have the CF SDK but it does not include a System.dll.

I'm using version 3 of the SQLServer CE. The SDK is installed using the SSCE31SDK-ENU.msi installer from MS.

Is there a specialised System.dll?

C

I think we're talking about completely different things.

SqlCE is only currently supported on the compact framework, thus on handhelds/smartphones. We're not currently supporting SqlCE on the desktop.

If you're using Sqlserver CE on the desktop, you've to wait till we update the DQE for sqlserver CE for the desktop in the upgrade version of v2.0 currently in development.

Are you developing a compact framework application or a normal desktop application? If you're developing a compact framework application, you have to start your application in vs.net with a different project type.

Hi

Yep - I'm developing for SQL Server CE on the desktop.

Can you let me know how long it will be before it is supported?

Further - would it be possible to use the one adapter such that it would matter little whether the app was acccessing a local DB (CE) or a server. This would remove the need to support two ORM APIs which are essentially a mirror image of eachother.

Thanks

C

cjarman66 wrote:

Hi

Yep - I'm developing for SQL Server CE on the desktop.

Can you let me know how long it will be before it is supported?

We hope to have support for SqlServerCE on the desktop with the upgrade currently in development. (v2.1). This is a free upgrade for v2.0 users. We're not done yet with its development, we hope to have a beta in a few weeks, though new drivers are developed during the beta period.

Further - would it be possible to use the one adapter such that it would matter little whether the app was acccessing a local DB (CE) or a server. This would remove the need to support two ORM APIs which are essentially a mirror image of eachother. Thanks C

Unfortunately, the adapter uses a pre-referenced DQE and the ado.net provider used by the DQE is different for CE than it is for normal sqlserver. You could use the same entities and 2 adapters, and create one using a simple factory you create which creates the right adapter instance based on an input value. Your code then targets IDataAccessAdapter and is db agnostic.

You need 2 projects as CE supports less types than normal sqlserver. This means also that you probably need type converters here and there to make everything work on server and client in the same way.

Thanks.

It is good to know that the one set of entities may be used - this is what I was looking to prototype when I ran into this issue.

Will look into the the adapter factory approach.

C