Visual Studio 2010 32-bit Windows 7

[Gaynelle Beltramo]

Thisraises some questions which I haven't got the answers to yet.I want to have the exact same code base.I must build with references to either the 32bit set of DLL's or 64bit DLL's.(Both 3rd party and SQL Server Compact)

Yes, you can target both x86 and x64 with the same code base in the same project. In general, things will Just Work if you create the right solution configurations in VS.NET (although P/Invoke to entirely unmanaged DLLs will most likely require some conditional code): the items that I found to require special attention are:

The assembly reference issue can't be solved entirely within VS.NET, as it will only allow you to add a reference with a given name to a project once. To work around this, edit your project file manually (in VS, right-click your project file in the Solution Explorer, select Unload Project, then right-click again and select Edit). After adding a reference to, say, the x86 version of an assembly, your project file will contain something like:

After reloading your project in VS.NET, the Assembly Reference dialog will be a bit confused by these changes, and you may encounter some warnings about assemblies with the wrong target processor, but all your builds will work just fine.

Solving the MSI issue is up next, and unfortunately this will require a non-VS.NET tool: I prefer Caphyon's Advanced Installer for that purpose, as it pulls off the basic trick involved (create a common MSI, as well as 32-bit and 64-bit specific MSIs, and use an .EXE setup launcher to extract the right version and do the required fixups at runtime) very, very well.

You can probably achieve the same results using other tools or the Windows Installer XML (WiX) toolset, but Advanced Installer makes things so easy (and is quite affordable at that) that I've never really looked at alternatives.

One thing you may still require WiX for though, even when using Advanced Installer, is for your .NET Installer Class custom actions. Although it's trivial to specify certain actions that should only run on certain platforms (using the VersionNT64 and NOT VersionNT64 execution conditions, respectively), the built-in AI custom actions will be executed using the 32-bit Framework, even on 64-bit machines.

This may be fixed in a future release, but for now (or when using a different tool to create your MSIs that has the same issue), you can use WiX 3.0's managed custom action support to create action DLLs with the proper bitness that will be executed using the corresponding Framework.

Edit: as of version 8.1.2, Advanced Installer correctly supports 64-bit custom actions. Since my original answer, its price has increased quite a bit, unfortunately, even though it's still extremely good value when compared to InstallShield and its ilk...

You can use a condition to an ItemGroup for the dll references in the project file.

This will cause visual studio to recheck the condition and references whenever you change the active configuration.

Just add a condition for each configuration.

While all other answers give you a solution to make different Builds according to the platform, I give you an option to only have the "AnyCPU" configuration and make a build that works with your x86 and x64 dlls.

Other Variants to try out: - You don't need the AssemblyResolve event handler if you assure that the right dlls are copied to your binary folder at start (Evaluate Process architecture -> move corresponding dlls from x64/x86 to bin folder and back.) - In Installer evaluate architecture and delete binaries for wrong architecture and move the right ones to the bin folder.

Not sure of the total answer to your question - but thought I would point out a comment in the Additional Information section of the SQL Compact 3.5 SP1 download page seeing you are looking at x64 - hope it helps.

Due to changes in SQL Server Compact SP1 and additional 64-bit version support, centrally installed and mixed mode environments of 32-bit version of SQL Server Compact 3.5 and 64-bit version of SQL Server Compact 3.5 SP1 can create what appear to be intermittent problems. To minimize the potential for conflicts, and to enable platform neutral deployment of managed client applications, centrally installing the 64-bit version of SQL Server Compact 3.5 SP1 using the Windows Installer (MSI) file also requires installing the 32-bit version of SQL Server Compact 3.5 SP1 MSI file. For applications that only require native 64-bit, private deployment of the 64-bit version of SQL Server Compact 3.5 SP1 can be utilized.

Regarding your last question. Most likely you cant solve this inside a single MSI.If you are using registry/system folders or anything related, the MSI itself must be aware of this and you must prepare a 64bit MSI to properly install on 32 bit machine.

that being said i think you should be able to keep a single code base for everything. In my current work place we have managed to do so. (but it did took some juggling to make everything play together)

The Visual C++ Redistributable installs Microsoft C and C++ (MSVC) runtime libraries. Many applications built using Microsoft C and C++ tools require these libraries. If your app uses those libraries, a Microsoft Visual C++ Redistributable package must be installed on the target system before you install your app. The Redistributable package architecture must match your app's target architecture. The Redistributable version must be at least as recent as the MSVC build toolset used to build your app. We recommend you use the latest Redistributable available for your version of Visual Studio, with some exceptions noted later in this article.

Unlike older versions of Visual Studio, which have infrequent redist updates, the version number isn't listed in the following table for Visual Studio 2015-2022 because the redist is updated frequently. To find the version number of the latest redist, download the redist you're interested in using one of the following links. Then, look at its properties using Windows File Explorer. In the Details pane, the File version contains the version of the redist.

Some of the downloads that are mentioned in this article are currently available on my.visualstudio.com. Log in using a Visual Studio Subscription account so that you can access the download links. If you're asked for credentials, use your existing Visual Studio subscription account. Or, create a free account by choosing the No account? Create one! link.

Visual Studio versions since Visual Studio 2015 share the same Redistributable files. For example, any apps built by the Visual Studio 2015, 2017, 2019, or 2022 toolsets can use the latest Microsoft Visual C++ Redistributable. However, the version of the Microsoft Visual C++ Redistributable installed on the machine must be the same or higher than the version of the Visual C++ toolset used to create your application. For more information about which version of the Redistributable to install, see Determining which DLLs to redistribute. For more information about binary compatibility, see C++ binary compatibility between Visual Studio versions.

These links download the latest available en-US Microsoft Visual C++ Redistributable packages for Visual Studio 2013.You can download other versions and languages from Update for Visual C++ 2013 Redistributable Package or from my.visualstudio.com.

These links download the latest available en-US Microsoft Visual C++ Redistributable packages for Visual Studio 2012 Update 4. You can download other versions and languages from Microsoft Visual C++ Redistributable Packages for Visual Studio 2012 Update 4 or from my.visualstudio.com.

I am calling C routines from fortran. I have abc.LIB and abc.DLL files for building a 32 bit application, and this is working very nicely. I also have abc_x64.LIB and abc_x64.DLL for building a 64 bit application. Is there a sample project among included example projects that shows how to get visual studio to be able to build either flavor?

As it is now, I have abc.LIB in the "source" list of files for the project. I believe that is the right way to do it. File abc.DLL not specifically named anywhere in the visual studio project, so I guess it gets that name from the LIB file. Do I also add abc_x64.LIB to the file list along with abc.LIB?

If both projects are Fortran, the better way is to have both the DLL and executable projects in the same solution. Right click on the executable, select Dependencies > Build Dependencies. Check the box for the DLL project and click OK. (You'll need to do this for both configurations.) What this does is automatically link in the output library from the DLL project - it also adds the module output folder to the INCLUDE/USE list for the executable project. Because the output folders are different for 32 and 64 bit, it will select the right one.

Unfortunately... several VS versions ago, Microsoft broke this for C++ projects when the dependent project is another language. What you'll need to do here is put the proper 32 or 64-bit path to the DLL export LIB in the C++ project's additional library directories property and give the name of the library under additional dependencies. Don't use the source file method for this.

In your case, you're calling C from Fortran. Unfortunately again, Microsoft broke linking dependent projects when the C/C++ project is a DLL - static libraries still work. Use the method in the previous paragraph instead. You'll still want to use Dependent Projects to get the build order right.

One does not name dependent DLLs when building, only the export LIB. Windows finds the DLL at run-time using its search list (includes PATH, folder where the EXE is, current directory, etc.), and 64-bit Windows will skip over a wrong-architecture DLL.

These other LIB and DLL files are all I have. I did not build them. I have the C header file for it, so that tells me it is coded in C. I will study what you said and see if I can figure out how to make it work. The fallback is to make two separate vfproj projects.

3a8082e126