I am trying to use the SQLite's .Net DLL to access some data on a local SQLite database. The problem is that i need a way arround this error because i need to develop a software for 32/64 bits platforms (by using VB.Net not C#).
How can i stick to the 32bit version of the DLL to allow 32bit users of my program use it too?
If it's not possible to work with the 32bit version of SQLite's DLL, is it possible to include both versions in my Installer and programaticly choose which version of the DLL should be used?
Or..is there any other way to access SQLite databases without this particular DLL? (Things in C/C++ are much easier when it comes to SQLite usage as i remember)
Thanks!
If you change your Target Platform to x86 instead of AnyCPU your code will be emitted as 32bit code also on 64bit systems and you could use just the 32bit dll of SQLite.
If you think that you are loosing some value working exclusively with x86 then I can give you this reference where the PRO and CONS of AnyCpu are critically examined.
To change the Target Platform use:
Menu BUILD, then Configuration Manager
Choose x86 from the Active Solution Platform combo.
If you don't have an x86 choice,
choose New and Select x86 and copy the default settings from AnyCpu.
Related
System.Data.SQLite (SDS) is apparently the most popular way to use SQLite from a .Net application.
I was wondering if
SDS requires shipping the SQLite DLL in addition, or if SDS includes
the SQLite source code, and
SDS can be statically compiled into a
VB.Net application of it can only be shipped as a DLL?
Thank you.
To expand on my comment, SDS is a .net wrapper for unmanaged code, so you will need to ship your release code with a copy of the DLL.
As Steve mentions, there are 32 and 64bit versions of the DLL, and as i discovered after much frustration, you must have the corresponding visual c++ runtime installed on the target machine, so if you deploy the 32bit version onto a 64bit machine, it will need the 32bit c++ runtime environment installed.
An alternative that i am currently looking into but havent had time to test is csharpe-sqlite, a pure .net implementation:
http://code.google.com/p/csharp-sqlite/
Coded in c# as the name suggests, but of course usable in any .net language including vb.net
Actually it's quite easy to compile System.Data.SQLite.dll to the does not require C++ runtime. For example if you download source code and follow the build procedures you'll find statically linked (no C/C++ runtime required) copy of System.Data.SQLite.dll in the following path:
<your-src-root>\bin\<2008 or 2010>\<Win32 or x64>\ReleaseStatic
For example if your source is in C:\Work\sqlite-netFx-source-1.0.80.0 then statically linked binary for Win32 and .NET 3.5 (VS 2008) will be located in:
C:\Work\sqlite-netFx-source-1.0.80.0\bin\2008\Win32\ReleaseStatic
Furthermore since System.Data.SQLite.dll is a mixed-mode assembly consisting of a managed .netmodule and native .obj file linked together using link.exe, it is possible to build your app as a .netmodule as well and link it together with SQLite into a single mixed mode assembly.
The resulting assembly will still be either Win32 or x64, however since almost all x64 machines will have no problem running Win32 code you can just settle on Win32 as long as:
Your app is an .exe or a .dll the is always loaded into a Win32 process, and
You don't use any of x64 specific advantages such as larger address space or using unmanaged code available only in x64
I have some .NET code that I am looking into porting into being a Windows Store app.
This code does a few different things and one of the things it does has a dependency on being compiled as x86 instead of AnyCPU.
Is this going to be a problem? Can a Metro app be compiled as x86 and still be distributed on the Windows Store? Is being compiled as x86 going to stop it from being able to run in Windows RT? Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it? (so, the main executable is AnyCPU and this one assembly is x86).
Can a Metro app be compiled as x86 and still be distributed on the Windows Store?
Yes. However, it would only be installable for x86 installations.
Is being compiled as x86 going to stop it from being able to run in Windows RT?
Since Windows RT is designed to run only on ARM CPUs, compiling for x86 will stop it from being able to run on Windows RT.
Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it?
You could use conditional compilation symbols to include/exclude functionality as required in your code. https://stackoverflow.com/a/6587823/61385 shows an example of how to do this.
Just compile whatever libs you need and when you upload to app store just upload the one you want to. Check your apppackages folder and look for the .appxupload files.
I have a C#/WCF application (hosted in windows service) which was deployed and tested on 32 bit Windows server. Now I need to deploy it for production. My network team suggested to deploy it on 64 bit Windows Server to take full advantage of server capabilities.
My questions:
Is there any performance gain in deploying an application on 64 bit OS? If yes, how much?
Do I need to do any special to make my application 64 bit OS compatible? If yes, what?
P.S. My application is compiled with "Any CPU" option (Does it matter?).
There is blogs of information out there on this. A quick Bing will bring up 1000s of talking points: http://www.bing.com/search?q=x64+vs+x86+server&src=IE-SearchBox&FORM=IE8SRC But, to be brief:
Is there any performance gain on deploying an application on 64 bit OS? If yes, how much?
The most noticeable benefit is memory utilization - specifically, your service/app, and all of the server's other services/applications, have more room to play. Only true if you have 4 GB or more of RAM. If you have less than that, you are actually wasting memory by each allocation of block.
The benefit, at the raw-performance level, is for every CPU cycle, you can execute up to 64bits of information, instead of 32bits - double the information. Significantly more noticeable with multi-threaded applications: e.g. Your WCF Service hosted in IIS, which is multi-threaded for the incoming requests. :)
Do I need to do any special to make my application 64 bit OS compatible? If yes, what?
Short answer, nothing what-so-ever. :) And that's the benefit of .NET, when you compile with the default "Any CPU" option!
When you compile code into assemblies, you are compiling code into an Intermediate Language (IL) - not actual machine code. The .NET CLR (Common Language Runtime) version, that is installed on the specific server/workstation/device that you are deploying to, is what takes your IL code and executes it in native instructions for that specific platform - x86, x64, or IA-64 (or AMD64, ARM, etc if there any tweaks utilized). You do not have to do anything!
As for coding practices, there is nothing specific to do either.
Referencing 3rd Party Native Assemblies?
Now, the only concern is if you are using referencing any 3rd-party assemblies through COM or alike that are compiled in native code (i.e. basically, 3rd party assemblies writting in raw languages). That becomes tricky referencing a 32-bit native assembly via a CLR on a x64 machine (basically, you have to force your application to complile to 32bit to access it). There are other work-arounds though, which is outside of the scope of this answer.
That's why I either: stick to all .NET references, reference only 3rd party assemblies written in .NET, just write it myself, or beg the author of the 3rd party component to release both 32bit and 64bit compiled versions. The latter becomes difficult to test on your x86 (32bit) machine as you can only reference the 32bit versions, but will have to deploy the 64bit versions.
More-of-a-headache is when dealing with your own WCF project, and those 3rd-party native assemblies, is that the built-in WCF hosting service in Visual Studio (as well as Cassini) is only 32-bit, as well as Visual Studio's IntelliSense. Yeah, it's fun when using 3rd party native assemblies and trying to debug applications on a x64 machine. Good times!
I am creating a wrapper around a native lib, which comes in both 32 & 64 bit flavors. I have a fairly complex C++/CLR project that includes a number of header files from the native libs. I got it to work fine on x32, but now I'm not sure how to provide an alternative x64 build.
Can someone outline the steps to create such project?
Various defines depend on _WIN32 / _WIN64, so must be multiple projects?
Both x32/x64 native libs have identical file names. Currently the lib ref is done with #pragma comment (lib, "xxxxxx.lib"). How should this be changed?
Lastly - VS2008 has only Win32 platform listed, not Win64 (I do have x64 VS2008 component installed).
Thanks!
Normally it is sufficient to select the drop down which says win32 (next to the Debug/Release one on the toolbar) and selected "Configuration Manager". Then open the "Active Solution Platform" drop down and select New. Choose x64 type (which if it doesn't exist then 64bit compilers are not installed) and copy solution from the orignal Win32 one. Now your project can be built selectively by changing the drop down on the toolbar.
Normally it works more or less as is but you might want to consider tweaking a few pre-processor defines if only for the intellisense.
As for libraries, for platform ones (supplied as part of VS/PSDK) then you dont need to change anything. For your libraries you are wrapping then change the Additional Library Directories in the project properties to point to the 64bit directory.
Visual studio doesn't always install the 64 bit options.
It can be fixed by running the VS installer, choosing add/remove features, and checking the x64 feature.
I heard on Windows x64 architecture, in order to support to run both x86 and x64 application, there is two separate/different sets of Windows registry -- one for x86 application to access and the other for x64 application to access? For example, if a COM registers CLSID in the x86 set of registry, then x64 application will never be able to access the COM component by CLSID, because x86/x64 have different sets of registry?
So, my question is whether my understanding of the above sample is correct? I also want to get some more documents to learn this topic, about the two different sets of registry on x64 architecture. (I did some search, but not found any valuable information.)
I ran into this issue not long ago. The short answer is that if you run a 32 bit application on a 64 bit machine then it's registry keys are located under a Wow6432Node.
For example, let's say you have an application that stores its registry information under:
HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX
If you compile your application as a 64 bit binary and run it on a 64 bit machine then the registry keys are in the location above. However, if you compile your application as a 32 bit binary and run it on a 64 bit machine then your registry information is now located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX
This means that if you run both the 32 bit and 64 bit versions of your application on the same machine then they will each be looking at a different set of registry keys.
Your understanding is correct. There wouldn't be any need for a x64 app to access the x86 CLSIDs since it could never load those components anyway and vice versa.
If you want to create component for use by both x86 and x64 then you need to either create a pair of dlls one built for x86 and the other for x64 and register both in their appropriate parts of the registry. The regsrv32.exe in the System32 folder will perversely register the x64 component and the regsrv32.exe in the SysWOW64 folder will register the x86 component.
Alternatively build a .NET assembly for Any CPU which can used by either CPU architecture.
They aren't separate registries--one is a subnode of the other, and the OS does virtualization to make sure that 32bit apps get their keys and 64bit apps get their keys.
Here is the Wikipedia article on the WOW64 registry which may give you some of the information you are looking for:
http://en.wikipedia.org/wiki/WOW64
I run an x64 bit machine as my desktop; and I have never run into any issues with the different registry configurations.
Per MSDN, there is apparently a difference:
http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx
HTH
How to register .NET assembly to be used as COM in pure 64-bit application?
Problem:
By default, if you enable "Register for COM Interop" in build settings, it DOES NOT register type library for 64-bit.
Solution:
To register your assembly which is not in GAC on a 64-bit machine, open cmd window and do:
cd c:\windows\microsoft.net\framework64\v2.x.xxxxx
regasm /codebase "path to your compiled assembly dll"
This will eliminate "Class Not Registered Error" when using native C++ to instanciate .NET assembly as COM object.