System.Data.SQLite

 I didn't use the design-time support either, so option 1 is fine for me.

Like others have mentioned, option 1 sounds good to me as well. I do not use any Design time features. Additionally, my guess would be that the size of the CF DLL would shrink a little bit without Design Time support (not that size is a problem).

Option1++

 

Hi,

 I think option 2 is most attractive.

It is also the same technique Microsoft uses for the System.Data.SqlClient and System.Data.SqlServerCe ADO.NET Data Providers so there is some familiarity there. Within the CAB files used to deploy these providers there are two atleast DLLs, one is managed and wraps the native one(s).

With the right configuration of Visual Studio it is possible to get the CAB file to automatically deploy whenever a reference to the managed assembly is added (this is how Visual Studio automatically installs the .NET CF or SQL Server Compact Edition cabs as required).

Perhaps this helps take care of some of the concerns around versioning?

Thanks,

Christopher Fairbairn

Windows Mobile Development Blog - http://www.christec.co.nz/blog/

I vote for option 1. I dont use designt time support either.

I vote for the 1st option too.

 Vote for option 1..No need for design-time on mobile apps..

What are the symptoms that we will see on Windows Mobile 6.1? Ie, if you don't do anything.

 

How about a new option?

I just spent the day ripping apart OBJ files and DLL's, and finally found a solution that solves all the problems!

In case you don't want to read the semi-technical jargon, here's the nutshell:

• I figured out a way to permanently workaround the CF strong name validation bug.
• The DLL will be strong named.
• Design-time support for the Compact Framework will live on!
• I've validated my results on WM6.1 and it works perfectly.

I've modified mergebin again, and this time it does a pre-link step which modifies the .OBJ file before it gets linked into a DLL.  It fixes up the .bss section (uninitialized data section) before the linker gets it.  Then after link, mergebin will zero out the .bss section.  It was this .bss section (being merged at link time with the .data section) that was causing the .data section's virtualsize to be larger than its rawdata size, and triggering the strong name validation bug.

So the workaround was to change the attributes of the .bss section before the linker gets it to trick the linker into expanding it completely, and keep it separate from the .data section.

For those of you who want the really nitty gritty details:
I edit the .obj file before link and change the .bss section attributes from read/write/uninitialized to read/write/initialized, which forces the linker to allocate space for the section block instead of making "invisible" space for it (and messing the virtualsize/rawdata sizes up).  It fills the space with garbage, but after linking, I reset the .bss attributes back to read/write/uninitialized, and zero out the section before merging the wrapper and signing the dll with a strong name.

Robert

At the risk of seeming fickle, I'm changing my position. I suggest keeping the native and managed DLLs separate: After having a brief look at the mergebin tool, I have gained just a little appreciation for the effort that has gone into wrapping the native and managed code together. To be honest I think this will lead to kludges down the track, for example the latest solution involving modifying .obj files before linking. This seems like such a large development effort just for the sake of not having two separate DLLs. And this may require even more of Roberts time in the future: maintaining the mergebin tool etc. Don't get me wrong, I'm grateful for everything the SQLite .NET developers have done so far. Even the most basic software development processes can deal with deploying two DLLs and version management of them. And who knows maybe in the near future Microsoft will provide the necessary functionality in the .NET CF toolkit to link native and managed code together. "Everything should be made as simple as possible, but not simpler."

Having developed it, I can certainly appreciate your concerns about the mergebin util.  It was basically developed out of sheer stubbornness not to let the Compact Framework box me into something I didn't want to do.  The thought process was: the desktop linker can mix native and managed code into a single assembly, why can't we do it on CE?  So I spent weeks researching the process of how the linker merged the two on the desktop.  Digging into the PE headers, reading the articles, examining the SSCLI (the source code behind .NET) etc.  Eventually I figured it out, and designed mergebin to do on the back-end what the linker does on the front-end.

So mergebin became the tool of choice.  The actual process of merging the two binaries is really simple.  A managed DLL is nothing more than a thin wrapper of native code to deliver a chunk of managed code.  In the beginning this was a really simple thing to merge.  Just make a hole, throw the managed code into it, fixup a few pointers, and re-sign it.

After trucking along for more than two years though, SQLite had made enough changes that I eventually encountered the strong name bug on CE.  For the last 6-8 months, its been a nightmare to deal with.  The hack I had in place was a Super Kludge (tm).  It worked for most CE environments, but finally met its match in WM6.1.  To be honest, I hated the kludge.  Every release I always wondered "is this gonna be the one that breaks it?"

What I've finally come up with today at long last, is a permanent fix.  The merged CF DLL is 100% right and doesn't kludge any of the numbers anymore on the CF, which is fantastic.  It's still one additional step that I have to make on the CF that I don't have to make on the desktop, but the step is pretty benign, and just basically prevents the linker from merging the .bss segment with the .data segment -- its a linker optimization I'm prepared to live without, especially if it gets me where I want to be with the strong name.

Robert

 

 

I've been getting reports that the Compact Framework DLL has not been working on certain WM 6.1 devices.  Personally, I'm running it on my own phone (WM 6.1) and it seems to be just fine, so this has been nothing I can reproduce.

I'm getting kindof tired of trying to squeeze a mixed DLL through the CF subsystem, so I'm thinking of changing the way I do this for version 59 and welcome some feedback.

The thing is, I really like the single DLL approach.  It's clean, eliminates the bug reports resulting from folks upgrading the wrapper and forgetting to upgrade the native DLL -- and allows multiple deployments using different versions to the same device without stepping on each other.

So as a temporary fix for version 59, I'd like to try the "embed the binary" route.  The SQLite .NET provider for CF would do something like this:
  - When first loaded, the .NET provider will look in the device's GetTempPath() for a SQLite subfolder.
  - If found it will look for a SQLite.Interop.XXX.DLL, where XXX is the matching version # of the .NET wrapper.  If located, it will load this DLL and use it as the interop DLL.  Initialization done and exit.
  - If not found, it will enumerate the SQLite.Interop.???.DLL files in this subdirectory and delete any versions older than XXX -- again, where XXX is the matching version # of the .NET wrapper.  After cleaning up any old versions, it will then write out the interop DLL from its internal resources, and load the DLL.  This cleanup only happens once, and only when a newer version of the interop DLL is being deployed for the first time.  Older deployments using older DLL's will still work and co-habitate.

 

I had a somewhat longwinded reply worked up about some issues with the embedded binary strategy, and then I noticed that you mention just the CF version ... can I infer from what you said that this route would only apply to the CF version, and not the desktop version?  The cleanup still has some issues (the interop dll should be removed at app uninstall, what if another app using an older dll is running when the newer version first runs, etc.), but those are fairly minor, and if WM does some level of automatic temp cleanup, are largely irrelevant.

Yes this is only for the CF version.  No changes are made to the desktop version, it continues to be a mixed-mode DLL.

As for cleanup ... when two apps are deployed with two different System.Data.SQLite libraries:

When the "new" version app runs and the "new" interop DLL does not exist, it will cleanup any "old" interop DLL's before writing the "new" interop DLL.
When the "old" version app runs and it detects that its old version interop DLL does not exist, it will cleanup any "older" interop DLL's before writing its "old" interop DLL to the temp folder.
From this point forward, anytime either app runs, both see that their matched interop DLL exists, and both run.  No cleanup is performed.  Any time an interop DLL is deleted, the above steps get repeated the next time the app that needs it runs.

 

 

Hi Robert,

The mixed-mode DLL was the most elegant solution we could hope for on .NET CF and with its demise we are going down the path of less elegant solutions. I'm not sure it's worth your while to continue try to work around the lack of support for mixed-mode DLLs in .NET CF.

IMHO having multiple deployments of different versions of SQLite is a bad idea from a configuration management perspective. Most Windows CE applications will be tested against a given version of SQLite and given the stamp of approval for that particular version of SQLite.  The SQLite DLLs will be in the same folder as the application, and not in the GAC.

I'd say most .NET CF VS solutions have a cab project that can include the native DLL in the application cab file, as well as the .NET assembly dependency. Also Visual Studio can automaticllay deploy the native DLL to the device, which will avoid using stale DLLs in a debug session. So I think the odds of a mismatch between the .NET and native DLLs are not so bad.

Perhaps in the .NET assembly, you could put a static class that checks the version of native DLL that somehow flags the mismatch to alleviate problems due to DLL version mismatches?

Thanks,
Carl

I think having different versions deployed is an inevitability when you have multiple apps made by multiple companies, deployed on your device.

So the idea is for them not to step on each other, and play as nicely as possible.  The most common scenario is as you described ... System.Data.SQLite.DLL in the app directory.  The question then becomes .. what to do with the native DLL?  The particular version of System.Data.SQLite is tied to a particular build of the native DLL.  So I want to actually put the version # in the name of the interop DLL.  I also don't want interop DLL's all over the place -- especially if they have the same name.  So that's why I chose the temp directory and the concept of sharing the native DLL.