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!
Related
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.
I have a project done in VB.NET and I want to publish it for distribution. I know that when I build solution It creates an .Exe. But that requires local resorouces. If I build for release I know it works but it still needs the .Net platform installed. Is there anyway to make a true standalone .exe or something that would run on a persons computer if they do not have .NET installed. Also the ClickOnce application thing is not a wanted Solution.
Is there any converter program that can do this for me?
The .NET framework represents the basic prerequisite to run a .NET program; equivalently than having Windows installed is the prerequisite to run a Windows program. Bear in mind that any Windows version includes the .NET framework (and, actually, it tends to involve top-priority updates and thus are automatically perfomed by Windows Update in many cases). A big proportion of the programs running on Windows created during the last 10 years are built on the .NET framework; a relevant proportion of the sites (like this one, for instance) are built on ASP.NET and thus the given server has to include the .NET framework. If overall compatility is a concern for you, you might rely on a-bit-old .NET version: the latest one in VS 2010 (4.0) should be fine for most of modern computers; but you can even rely on the previous one (3.5) to be completely sure. Lastly, bear in mind that a .NET program can also be run under a OS other than Windows (Linux or MacOS, for example); although, from my past experiences, these are not too reliable situations. Nonetheless, in case of being interested in other OS, you should do some research/testing on this front to see if the available options offer what you are looking for.
SUMMARY: the exe file generated by the Visual Studio is actually what you call "standalone .exe". One of its defining features is the .NET version (which can be changed in the Project Settings); a program can only be run on computers with a .NET framework (or equivalent) equal or newer than the one on which it was built. The 4.0 version should be OK for most of new/properly-updated computers; the 3.5 .NET would work with virtually any computer (although, logically, it includes less features than the 4.0 one).
---------------------------- UPDATE AFTER COMMENTS --------------------
From some comments, I have undertood that my statement wasn't as clear as I thought and this is the reason for this update
.NET is pre-installed in Windows only since Vista. XP does not include the .NET runtime by default. The reason for not having mentioned this issue in my answer was that having a XP Windows without .NET is highly unlikely. Firstly because this is a top-priority, automatic update and thus one of the first times the computer is connected to internet "Windows Update" will take care of this. And secondly because this is the basic framework for any Microsoft programming over the last 10 years and thus a Windows computer not having it will not be able to run almost anything. With this last sentence, I don't mind that most of the programs are built on .NET, but that for a Windows-based environment most of nowadays basic requirements do include .NET.
It was also pointed out that there is some compatibility problems between different .NET versions (that various side-by-side versions were required). The basic Microsoft approach to the different .NET versions is backwards compatibility, what means that a given .NET version can run any program built with that version or older. This is theoretically right, but not always right in fact. My approach to this problem is relying on a bit old .NET version (3.5) and not using too new/untested features (e.g., WPF). If you want a for-sure overall compatible program you should work quite a lot on this front (compatibility between versions is one of most typical problem of any programming platform), instead expecting Microsoft to take care of everything. Thus, in principle, just one .NET version (the last one) has to be installed (which, on the other hand, is not the case for a big proportion of computers; for example: computer including the 3.5 version being updated, over the years, to 4.0 and 4.5 by maintaining the previous versions).
Lastly, I want to highlight that my intention with this answer is not defending any programming approach over any other one; I am just describing what is there from the point of view of your question "can I remove the .NET part?" -> no, you cannot; there is no (sensible) way to do that. If you want to rely on a different programming platform you should get informed about it (I am sure that Camilo Martin will be more than happy to help you on this front). If you prefer to rely on .NET, be sure that you can generate an overall compatible program (to be run on Windows).
Easy way to convert in .exe in VB.NET-2010:
Create New Project
Select Windows Application And Save Proper Path
Comple Project then Select File-> Save All
Select Build->Start Build
Your Project .exe Created Your Project Save Path:
Select Windows Application 1
Select bin Folder
Select Debug Folder
And in Debug folder your .exe File is ready.
Quick Basic once made and executable (.exe) directly form their VB code, but I wouldn't recommend converting to Quick Basic. You can look at Mono to see if they have anything yet. (mono allows you to use compiled vb.net in other operating systems).
Ezirit Reactor makes a single executable, but it's not free.
You can bundle .NET Framework into your distribution so that users don't have download it.
Why do you need an executable (.exe)? If the reason is for security and to minimize chances of reverse engineering, then get a good obfuscator.
I have a 64-bit-only application that I am developing in Objective-C on Cocoa. It includes various plugins that are also 64-bit. One of these plugins needs to use a 3rd party Framework that is only built for 32-bit i386. It is a C-based framework. It is not possible for the 3rd party to produce a 64-bit version at this time.
I do not want to change my entire application and plugin suite to be 32-bit just to accommodate this one 32-bit framework, but I also do not have any alternatives since it provides access to a proprietary piece of hardware and is the only means my application (via the plugin) will have to operate the device.
What are my options for making this all work?
Clearly my plugin needs to be 64-bit, otherwise the main application will not load it. However, In that case I cannot link against the 32-bit external Framework. I have read that I may need a 32-bit helper application that the plugins communicates with, but have no idea if that is a good or recommended approach.
Are there any other ways to do this? If not, can someone point me to any documentation or tutorials on making this work?
An option would be to create a standalone 32-bit application that uses the framework and controls the device. Then have a 64-bit plugin to your app that launches the standalone app and communicates with it through some IPC mechanism.
I've built and installed my service from vs2010 onto a 64bit machine.
My problem comes in when my service references 32 bit dlls (spssio32.dll to be precise) - I get the error in my event viewer : "System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
Any help on the matter would be appreciated.
Regards,
Byron Cobb.
Is your service code written in a .NET language? If so, you need to mark it as targeting x86 rather than Any CPU (via Project properties / Build / Platform target).
(By default, .NET code targets Any CPU, meaning that on 64-bit machines it will compile into x64 machine code. Because such 64-bit code can't load 32-bit DLLs, that can lead to failures like the one you're seeing. Where code has a dependency on a 32-bit DLL, it needs to always compile to 32-bit machine code even on 64-bit machines, hence setting the target platform to x86.)
You can use a COM surrogate
http://www.dnjonline.com/article.aspx?id=jun07_access3264
The other variant is to spawn an external 32 Bit server-process and add a .NET remoting interface to it and your 64 bit application, so you can use .NET remoting for interprocess communication.
I am working on an application that has more than a few dlls written in VB6. VB6 code includes COM dlls and ocx controls. The rest of the code is in C++ and C#. I have been assigned the task to make the application code base compatible with 64bit architectures. Loads of help material is available for C/C++ code so thats not a problem at hand. But it isn't easy to rewrite all of this vb6 code into .net or some other language to make it compatible with 64bit. Neither do I understand all the underlying logic so just assume that rewrite is out of question.
On the other we all know that VB6 dlls wont work in 64bit environment. So what are my options.
1) covert each of the dll into an EXE which will be loaded in 32bit and it can interact with my rest of 64bit application via COM interfaces. Do you foresee any problems with this approach?
2) I edit the registry and load all the VB6 dlls out of process, make them load in dllhost.
3) Make a single 32bit exe, refer all of these VB6 dlls in that exe and load that exe in 32bit address space and the 64bit part of my application communicates with the 32bit exe.
The major problem that comes to my mind with all of the above mentioned approaches is what to do with OCX controls????
Any ideas?
If no new ideas than which of the above mentioned will be preferred by you and why?
If you have lots of existing VB6 code that uses to run in-process, I'd first question if migrating to 64 bit is really worth the effort. 64 bit has many advantages for server apps, but for desktop apps, 32 bit is often completely sufficient. And as WOW64 can be expected to be available for at least a decade, there is little speaking against running 32 bit apps on 64 bit Windows.
The point is, although it is possible that by using out-or-process servers you could tweak your app so that it runs at least partially in 64 bit mode, this will probably have a significant impact on performance (and also on memory overhead). Odds are that the customer therefore has absolutely no benefit from choosing the 64-bit version of your app.
That said, I'd say 2) or 3) would be the natural choice. 2) is certainly easier to implement, but 3) gives you more control of how many out-or-process servers should be created and how their lifetime is managed.
I'm migrating from SQL 2000 x86 to SQL 2008 x64.
Here we are facing a similar issue. I've decided to use DCOM.
How will does it work?
A server 32-bits will host the assembly and the 64-bits machine will call using DCOM.
There is performance penalty. BTW, the effort in comparison to rewrite... certainly worth be doing.