We are having one problem while compiling with 64bit dlls. We are having lots of classlibray in our project and one webapplication. and when comiple it with x64 plateform with 32 bit operating system its compiling but when we move that thing into production environment which is 64bit operating system then its giviing error that one of assambly is not able to load. Can any one have any idea for that? All the class library is also on comipleted x64 option.
I don't really understand your question, so this is not really an answer, but I think it's worth mentioning.
Depending on what you are doing, some COM libraries and third-party Assemblies will require you to run on WOW64. Try doing a fresh rebuild of all the components in your project, and instead of compiling for "Any CPU" compile for "x86" and deploy that. This should force your assembly to run in 32-bit mode on WOW64, and therefore may make your third-party libraries happy.
Related
Feels like a silly question, but I'm struggling to find the answer online: Is it possible to deploy Qt apps to Windows if you did development on a Linux machine? It seems the answer should be "yes", but I can't seem to use windeployqt on my linux machine.
If it is possible, what additional resources do I need to do this?
Yes, it's of course possible.
You have to cross-compile Qt using the MinGW compiler, targeting Windows.
You'll have to patch and build windeployqt yourself. By default, windeployqt is looking for g++.exe in the path. Of course this makes no sense on a linux build host, so you'd have to tweak it so that it finds the correct compiler and runtime libraries.
You can then build your application using the cross-targeted Qt build, and deploy all the necessary artifacts into some deploy folder using windeployqt.
To package the deployed build, you can run nsis or wix on Linux as well, to obtain a Windows installer. You can even sign the executable files (required these days for Windows), there's an open source tool called osslsigncode - it works on most platforms and doesn't require Windows.
It'll take a bit of time for you to figure it all out. It's certainly easiest to just build on Windows and not mess with it. But if you insist on building on Linux - you certainly can.
A solution containing my MVC application is having nearly 20 different projects (one of them is MVC, few are WCF service applications, and the rest are class libraries.
They all work, and gets build fine.. but the issue is they are giving warnings related to platforms while doing build. I have checked in the configuration manager that some of them are set as "x86" platform, and some of them are set for "Any CPU" and I feel I receive the warnings due to this.
As a developer, and in order to support cross-platform, I think I need to set all projects under this solution to target "AnyCPU".
I would like to know if this is the safer approach? or if there is any risk involved during deployment?
Any inputs over this, much appreciated.
AnyCPU is the least restrictive and should be fine. x86 will restrict to 32-bit process and require running in WOW64 mode on 64-bit platforms. x64 will limit it to 64-bit. AnyCPU creates DLLs that can run in the current loaded process (whether it is 32 or 64 bit). This should be the option unless you have some sort of limitation or optimization that requires you to target a specific platform.
PresentationCore.dll and WindowsBase.dll are both included with the Microsoft .NET Framework 3.0, and two versions of each dll are installed to disk:
An x64 version under C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0
An x86 version under C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0
Until adding references to these dlls, our ASP.NET web app was able to be compiled for "any CPU" and would run in either 32bit or 64bit mode with no issue. After adding a reference to, say, PresentationCore via the standard "Add Reference" dialog (Add Reference -> .NET -> PresentationCore), the web app fails when in 64bit mode with the following error:
Could not load file or assembly 'PresentationCore' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Clearly this is because the 64bit app pool is trying, and failing, to load a 32bit version of the PresentationCore dll.
Now, I'm a little confused by this...
Other .NET Framework dlls seem to switch between their x64 and x86 version seamlessly (loading from Microsoft.NET/Framework64 or Microsoft.NET/Framework, respectively). Why are PresentationCore and WindowsBase any different?
Why does Visual Studio appear to only offer me the 32-bit version under the ".NET" tab in the "Add Reference" dialog? If I want the 64bit version, I have to "Browse" for it.
Is there any simple way to automatically have the correct dll selected, like seems to happen for other .NET Framework libraries?
We can always write a bit of MSBuild xml that will automatically swap references at build time based on the bitness of the target environment, but that seems like something we shouldn't have to do for .NET Framework dlls. What gives?
Thanks!
It is possible to conditionally reference each the .dll file that matches your active build configuration. You'll need to manually edit your project file. Add a reference to the 32-bit DLL. Then save the project and edit the .csproj file in a text editor.
Search for the reference that you added and add Condition="$(Platform) == 'x86'" as an attribute on the Reference element. Then make another copy of the Reference element and tweak it for the x64 version. Here's an example with the Oracle ODP.NET drivers:
<Reference Include="Oracle.DataAccess, Version=2.111.6.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=AMD64" Condition="$(Platform) == 'x64'">
<SpecificVersion>False</SpecificVersion>
<HintPath>lib\x64\Oracle.DataAccess.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Oracle.DataAccess, Version=2.111.6.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86" Condition="$(Platform) == 'x86'">
<SpecificVersion>False</SpecificVersion>
<HintPath>lib\x86\Oracle.DataAccess.dll</HintPath>
<Private>True</Private>
</Reference>
One important thing to note is that you'll no longer be able to use the 'AnyCPU' configuration. You will need to have explicit build configurations for x86 or x64. The .dll you are trying to use is likely making native calls into OS libraries so your project can no longer be platform agnostic.
If you only want to maintain 1 build configuration, you can go with x86 and use only the x86/32-bit version. If it's a web application, you will need to put the app pool into 32-bit mode.
Edited to answer your original qeustions
You have a handful of platform options when you build a dll/executable: Any CPU, x86, x64, or Itanium. Code that is written 100% in managed code and has no dependencies on native libraries are generally compiled & distributed as AnyCPU. This is because the resulting intermediate language (IL) code generated by the compiler can run on the x86, x64, and Itanium versions of the .NET Framework. Libraries that target Any CPU can be referenced safely from applications that are platform specific (x86, x64, IA64). The reason that PresentationCore and WindowsBase are different is because they have dependencies on native code. Unlike IL-code, which is interpreted at runtime, there is no concept of Any CPU in native code. Because of the native code dependencies, the PresentationCore and WindowsBase .NET libraries needed to be distributed as x86 and x64, as AnyCPU is not possible.
The Add Reference dialog should only show you libraries that are compatible with the platform that you're targeting. If your Target Platform is x86, it should only show you Any CPU and x86 libraries.
Unfortunately, no. If you can't use Any CPU, but still need to support x86 and x64, then you need to setup multiple build configurations (one for x86 and one for x64) and conditionally reference the 32-bit and 64-bit dll's you need. The only way I know of to do this is to edit the project file as detailed above. You will need to build both configurations and distribute separate 32-bit and 64-bit versions of your code as well. If anyone depends on your code, they will need to jump through the same hoops.
I am new to Qt, and I am working in Windows 7.
When I try to run my application directly, I see an error about missing some DLLs. I tried to fix them, but I could not (I tried to build statically).
Is there any correct solution?
My question is:
If I want to run my Qt application on other computers, what do I need? For example, for a .NET application we need to install the .NET framework on the target computer, but what about for Qt?
I searched for its SDK and found a SDK that was about 1.6 GB! Does this mean every time I want to install my application I should install a 1.6 GB sized SDK? That's far too bad.
Thanks.
You have to distribute your application with needed libraries.
If your application is running on Windows you can follow this guide: Deploying an Application on Windows. You can find needed libraries as dll in bin directory inside SDK. A basic Qt gui application needs at least QTCORE4.DLL, QTGUI4.DLL and, if you are using Qt Creator, MINGWM10.DLL. You can leave these libraries in the same directory as you application.
You can't link statically against Qt unless you have built the libraries in that configuration (which you won't if you've just downloaded the pre-built SDK). Be aware that if you do want to link statically there are licensing implications for some components.
If you have built a release configuration then you will need at least the libraries Alessandro mentioned, QtCore4.dll and QtGui4.dll. Depending on the other parts of the library you're using you may also need QtXml4.dll QtWebkit4.dll, QtXmlPatterns4.dll and possibly Phonon.dll. Check that you are building a release configuration rather than a debug configuration, as this won't run as it needs the Visual Studio debug runtimes, which you can't redistribute. If you are in doubt which dlls you need then use DependencyWalker to find out (note that this doesn't show Phonon.dll as it is loaded later).
Generally you'll only need about 4-6 of the dlls, you won't need the whole SDK.
Please consider that many applications use Qt, you have some real chance the DLLs are already installed. Anyway, beware of MSVC dependencies: we had some real nightmare deploying applications on some server, partly related to a policy switch from VS2005 to VS2008. Alessandro already given a good resource: see also this previous post.
If you're working with Qt5, besides the .dlls mentioned by the first answer, you must also add the platforms/ folder from the bin directory inside the SDK.
Are there any compatibility issues that would prevent this from working? Do I need to have a 32-bit VM to use when working on projects for this team?
No. Should work perfectly well.
Read a little here: http://msdn.microsoft.com/en-us/library/ms973190.aspx
I run Vista 64 and the other members of my team run XP 32 bits, the only issue we've had so far was with a third party COM-component where the interop assembly wasn't easy to generate on the 64 bit machine. Once it was generated it screwed up the other machines. That was fixed by generating the interop assembly on the 32-bit machines and checking it into source control.
I heard in the latest .Net-rocks podcast that setting x86 instead of "Any CPU" in the build configuration should resolve a lot of problems, but since I haven't had any problems other than the one I described I have not yet tried that.
It doesn't matter what your environment is, develop on whatever machine you wish. I would be concerned about the QA, staging and production environments. If they are all 32 bit, I would want a 32 bit VM to test my code.
I'm not sure about collaborating with other developers in a different windows 32/64-bit environment, but I can speak about deploying an .NET application that was developed in Windows XP 32-bit on a Windows 2008 64-bit server.
The only problem I had was with an application that relied on a 3rd-party assembly. We only had a 32-bit version of the assembly. So, in order to run our application in a 64-bit environment, I had to compile my project for x86 (as you described). It solved everything.
All other applications I was able to get running without changing a thing (they were compiled in the 'Any CPU' mode.
I suspect you won't have problem unless you have some external assemblies. If that's the case, then you will either have to recompile them or simple force your project to compile to x86.
I know that doesn't definitely answer you question, but hopefully it helps.
Andrew