In one project's Properties | Build tab, only x86 is available for Platform. The x64 build option is missing. This is occurring in one project of a solution. The other projects are all still using x64. I tried creating an entirely new and separate solution/project and it is also only displays x86. Also, in the General section x64 is available and selected for Platform Target.
Can anyone explain why this is happening and how to fix it?
Related
In all of the component projects of my C# solution, "Platform target" is set x64 in Project>Properties>Build. However, the Platform property is still "Active (Any CPU") and that is the only option. In the build log, I can see that it is copying both x64 and x86 versions of some nuget packages. Two questions:
If I've specified why x64, why is it still copying x86 packages?
Is there way to eliminate "Any CPU" as a platform option and ONLY build x64?
The Platform target under Project>Properties>Build is not the right option for your build process. That option is to tell which platform the project assembly is compiled for rather than your nuget package. So, the option cannot change the build platform and your nuget package still uses the build platform to judge which version of the dll is copied into the main project output folder.
More info you can refer to this document.
Suggestion
You can use Configuration Manager under Build
You should locate your Project and then choose x64 to build your Project Platform. And if you did not have x64, you have to click New to create it.
Update 1
Your Build Configuration is in a mess. So please first enter each project Properties-->Build--> change Platform target to Any CPU to do a restore operation.
Then, enter your Configuration Manager, delete any x64 and x86 platform under Active Solution Platform and Project Platform if you have. Then, click Active Solution Platform and then create a new x64 platform.
This will set uniform platform settings for each project.
You can refer to this similar issue.
I have a visual studio 2019 project that requires a 64 bit build due to dependence on some nuget packages.
As you can see, I have changed the build targets to 64-bit but it doesn't seem to be able to move past the same complaint.
What am I missing here? Is this a bug in Visual Studio 2019 or am I doing something wrong?
Changed all built targets to 64 bit.
While you're looking at the specific build options for a Configuration called "All Configurations", where the Platform is set to "X64". But note your settings in your IDE's toolbar. You're currently targeting/building the "Debug" Configuration for "Any CPU".
To better understand what's going on here, right click on your Solution node in the Solution Explorer and select the "Configuration Manager..." menu item.
Given you require X64, you can/should remove the configurations that allow you to target x86 or ANY CPU. I suspect you are just building the wrong configuration here. That "All Configurations", is probably being brought along by one or more C++ projects in your solution.
Sincerely,
I have MFC Dialogue based applications written in VC++6.0. Due to my work environment requirements I need to upgrade to Visual Studio 2010. I don't need to add any new feature, just compile with the upgraded visual studio.
Can any guide me on this?
What are all the primary requirements and how to start it?
Just open the project/solution in VS-2010. Convert it and compile.
You might get some compiler warnings/errors depending on your code, because the new compiler is more precise.
But most conversions lead just to a view warnings, like security stuff and others and should work directly.
From the VC++ team blog and Visual Studio 2010 C++ Project Upgrade Guide:
With Visual Studio 2010, C++ build system moved from the VCBuild based system to the MSBuild based build system.
The C++ project system is also built on top of the MSBuild build system.
There are some limitations, known issues or by design changes that you may run into during the upgrade process.
VS2010 supports upgrading from VC6, VS2002, VS2003, VS2005 and VS2008.
As in previous versions of Visual Studio, upgrade can be done either through IDE conversion wizards or from the command line (Devenv.exe /upgrade).
Here are the recommendations for upgrading your applications:
1) Set up the upgrade environment the same as your build environment
The upgrade process will try to load files and evaluate values during upgrade. If your projects use values that are not defined by the project files themselves, for example, values defined by environment variables, it is required that these environment variables are set up before doing the upgrade. Without these environment variables properly set up, you may get conversion warnings or errors caused by unevaluated values.
2) Make sure you have the required platforms installed before doing upgrade
Converting a project on a machine without all the available platforms for the project will result in a conversion error. For example, if you try to convert a project with Itanium Platform on Visual Studio Professional SKU, which does not support the Itanium platform, you will see a conversion error like the following:
Failed to upgrade 'Debug|<Itanium>'. Please make sure you have the corresponding platform installed under
'%vctargetspath%\platforms\Itanium'. Cannot load the project due to a corrupt project file. The following error
has occurred during XML parsing:
File: D:\Sample\ConsoleApp\ConsoleApp.vcproj
Line: 28
Column: 5
Error Message:
System error: -2147154677.
The file 'D:\Sample\ConsoleApp\ConsoleApp.vcproj' has failed to load.
This is by design as the conversion needs to evaluate the properties in the missing platforms to do a successful conversion. You can verify which platforms are installed on your machine by looking in the following directories: %ProgramFiles%\MSBuild\Microsoft.cpp\V4.0\Platforms (or %ProgramFiles(x86)%\MSBuild\Microsoft.cpp\V4.0\Platforms on x64 machine) for the Platforms installed on the machine.
3) Use native Multi-Targeting to build against VS2008 toolset first if possible
In VS 2010, Native multi-targeting have been added which allows you to build against the Visual Studio 2008 toolset from within the VS2010 IDE using the new MSBuild-based project system. I recommend you to take advantage of this feature by using VS2010 to build against VS2008 toolset first when upgrading. This can help isolate any project system/build system related issues from the tools issues that you may run into after upgrade. This will make the move to the VS2010 toolset much smoother.
Upon upgrade, the property sheet files (.vsprops) are converted to their new format (.props). Likewise, project files (.vcproj) are converted to their new format (.vcxproj). Note, the new project files are generated alongside the old project files. A new file type (.filter.vcxproj) is also generated during conversion. The filter files contain the information that is used to display folders in the solution explorer. This filter information was originally part of the project file. This change was necessary because MSBuild requests a rebuild whenever the project files changes. By storing filter information in a separate file, the filter can be changed without triggering a rebuild of the entire project.
Note: Upgrade process will not convert the .user file. As a result, your debugging and deployment settings will not be preserved after conversion.
In VS2010, a new command line upgrade tool, VCUpgrade.exe is introduced. This command line tool is suitable for upgrading applications with only one project as it cannot take in solution file as input and parse solution information into project files. VCUpgrade.exe is located at: $(VSInstallDir)\common7\Tools directory. This tool will also be shipped in the next release of WinSDK so that the users can do command line upgrade of the project files shipped in WinSDK without Visual Studio IDE.
After moving my build server I get the following error:
C:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft.Common.targets (1682): Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR2" and architecture "x64". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "MSBuildTaskHost.exe" exists and can be run.
My configuration says this:
<ConfigurationToBuild Include="Release|Any CPU">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
What am I missing?
To resolve this, Go to your .csproj file and open with notepad.
Add the following line under the default property group:
<PropertyGroup>
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
Project should compile now.
In my case, I received that error message when trying to build a solution on a 32-bit Windows 7 machine. The way to resolve the error for me was to right-click on the project in VS, choose properties, then go to the Build tab. In here I changed the "Platform target" from "Any CPU" to "x86". HTH
Another approach is to do the following
Click Start ->> right-click Computer ->> Properties ->> Advanced system settings ->> click Environment Variables button to open the dialog,
then under the System variables section, click New… button, type the
Variable name = DISABLEOUTOFPROCTASKHOST, and type the Variable value = 1,
then click Ok.
This should suppress this error.
You need to install .NET SDK for the version of .NET that you are using.
Here is a link for .NET 3.5
Where is the .net 3.5 SDK?
and here is a link for 4.0
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Installing Visual Studio will install the right SDK as well, but may not be a good option for you.
I hope that helps.
The core problem is the fact that an 64-bit executable can not load a 32-bit dll and vice-versa.
"Auto" means that . NET assembly will switch at runtime between the platforms, depending on what platform is on the machine it is currently running on.
So having a .NET assembly compiled with "Auto" loading an 32-bit dll is a problem waiting to happen, and this is what this error is all about.
To correct it, if you are NOT using any native dlls, go to the properties of the project for every managed project and set "target CPU" to be the same as currently selected "Platform", for all available platforms.
If you are using native dlls, you have to define 2 build configurations one for 32 bit and one for 64 bit, link (refer) the correct versions of the dlls and install according to the target computer platform.
I resolved this issue by opening VS2010 as administrator.
I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.
According to Li Shao's (of Microsoft) 2009 blog entry:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.
This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?
HELP!
Have a look at Daffodil: http://daffodil.codeplex.com/
After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.
I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.
When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.
Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?