System.Data.SQLite

July 10, 2008 -- The problem has finally been solved (see my posts in page 2). 

I'm in a tough position regarding Windows Mobile. 

• There are numerous design-time issues related to the undocumented ways that Visual Studio 2005 and 2008 allow Compact Framework projects to design datasets and work with bindingsources.  I've probably made more progress on this than anyone before me, but I've literally spent hundreds of hours on this.
• Since I combine the wrapper and the native DLL into a mixed assembly, it has revealed a bug in the strong name validation code on the Compact Framework.  Status (or lack thereof) on the reported bug can be found here.  I've been working around this bug, but it was recently discovered that the workaround fails on Windows Mobile 6.1.  I didn't like the workaround to begin with, but this puts the nail in the coffin.

So the question on the table is what to do?  Here's my options:

• Remove the strong name from the Compact Framework assembly
• PRO: I can continue to combine the two assemblies as before, and things will work nicely on WM6.1 and likely future Mobile editions.
• CON: Kiss what little design-time support the CF version had goodbye.  Without a strong name, nothing else works in the designer for CF.
• Split the two components into managed wrapper and native assembly.
• PRO:  I can keep the digital signature
• PRO:  There's a possibility I can continue supporting design-time features for CF
• CON:  There'll be two assemblies to distribute with your applications, and one of them will be unmanaged.
• CON:  With two assemblies comes version control issues.  The specific version of the wrapper is tied intimately to the native DLL and you can't mix the two.  No effort is (or will ever) be made to make the wrapper backward or forward compatible with any other native DLL than the one it was released with.

Any suggestions?

Here's a 3rd option:

Add the native DLL to the assembly as an embedded resource and unpack it (if it doesn't exist already) when you first call into it.

• PRO:  Distribution is still a single file, technically.
• PRO:  Keeps the strong name and probably design-time support
• CON:  Bloats the overall footprint by a few hundred kb because I have to store the DLL with the assembly as well as on the device.

 

In the case of a managed and an unmanged assembly: would it be possible to use the managed assembly for both desktop and CF .NET versions? I would appreciate that because it would make it easier to write assemblies for both platforms. See also http://sqlite.phxsoftware.com/forums/p/1120/4754.aspx#4754 for details.

That's not an option.  The Compact Framework doesn't have support for a lot of ADO.NET features found in the desktop framework.  It's not possible to have one managed assembly service both platforms without seriously gimping the desktop down to Compact Framework level.

 Personally option 1 sounds fine, does anyone actually use the design-time stuff for Windows Mobile apps?

 

 I'd say Option 1 too. I do not use any design-time stuff on WM.

Hi Robert,

I'd choose option two. You don't loose functionality and the versioning is something
I can deal with. Especially if mixing of different versions is prevented.

Alexander

I'm not familiar with the design-time feature of the wrapper as I never had to use it so the first option would fit me too.

However, could not it be possible, using option 1, to add to the current installation package a DLL which purpose would only be to support the design-time feature? That is, keep the current DLL to be deployed/installed on devices but let Visual Studio use other files (something like option 2)?

Again, I have no idea of what can be done with Visual Studio and its design-time features regarding platform/DLL issues.

My preference is option 1 as well.  Primarily because all of the CF design-time experience is undocumented and there's never going to be a case where I can say "yes, this works and will continue to work in the future when MS issues service packs or new versions".

 

lisurc:

However, could not it be possible, using option 1, to add to the current installation package a DLL which purpose would only be to support the design-time feature? That is, keep the current DLL to be deployed/installed on devices but let Visual Studio use other files (something like option 2)?

This won't work.  Visual Studio takes care of automatically adding references to assemblies, and uses those references during design-time to background compile your datasets so it can provide intellisense and other things.  It's a  pretty convoluted process for the Compact Framework and I have to do a lot of bait-and-switch tactics to even get it to work at all.

 

Option 1 for me too please. I have never used the design-time support.

I vote for option 1 too.

All in all, I really don't care that much, since most apps consist of a couple of modules. But I haven't used Design Time support at all, so I won't mind loosing it.

Just to be curious:

How much effort would it be, setting up the project in a fashion so that it produces two different CF outputs. One for option 1 and one for option 2, so we could decide on our own, which version to use.

Tilman

That's why I give you the source code -- so you can have your own options!  Basically my goal is to make my life as simple as possible when producing code updates and new releases.  If I have to prebuild and test a bunch of different code compiles and variations, I'm going to be much less inclined to release a new version regularly.

 I vote for 1 too.

 

Regards

I vote for the first option: Remove the strong name. After all if the source is available, those that need a strong name can build the assembly from source. If this is truly a .NET CF bug, then remove the work around and just document the bug in release notes. Hopefully MS will provide a hot fix, it's unlikely though.