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.
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.
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?
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?
Trying to build a project that uses managed C++/CLI and it compiles successfully when in the 64-bit build config. When I switch to Win32 config it fails siting the managed C++/CLI dll is not a strong named assembly. When switching configs I have verified that both have the Project -> Configuration Properties -> Linker -> Advanced -> Key File entry has the proper path to the snk file ($(SolutionDir)key.snk)
Not sure if I'm missing something here. I haven't been able to find anything on Google...
[UPDATE]
If I use a post build event in the C++/CLI project the output window shows the following error:
c:\path\file.dll does not represent a strongly named assembly
I'm using the following post build event:
sn -Ra "$(TargetPath)" "$(SolutionDir)key.snk"
Again - the above post build event works on the x64 config but not the win32. (I have tried compiling on both 32-bit & 64-bit machines w/ same result)
Just ran into the same problem today, after some digging it looks like this is caused by a bug introduced in Microsoft Visual Studio 2010 SP 1.
A description of what caused the bug and a workaround can be found at the following link:
http://blogs.msdn.com/b/vcblog/archive/2011/03/11/10140139.aspx
I have a VS 2010 solution that contains a website that has a web service within it. The web service references a COM dll that is causing problems when the solution is built on our 64-bit build server. I get the typical 32/64-bit error:
ASPNETCOMPILER : error ASPCONFIG: Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect format
When I build the site using the 32-bit aspnet_compiler it builds okay. So, how do I specify that a website should be built as 32-bit? The Configuration Manager within VS will only let me choose Any CPU, so I cannot change it to x86 for this website...
Thanks.
You can use the following command. Actually, in this case you are using ASPNetCompiler x86 edition to build your own project
call "C:\Program Files\Microsoft Visual Studio 2008\VC\vcvarsall.bat" x86
MSBuild MySolutiuon.sln
You can also use x86_amd64 for any cpu. Note that instead of using MSBuild you can load your confiiguration like
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="PrecompileWeb">
<AspNetCompiler
VirtualPath="/MyWebSite"
PhysicalPath="c:\inetpub\wwwroot\MyWebSite\"
TargetPath="c:\precompiledweb\MyWebSite\"
Force="true"
Debug="true"
FixedNames="True"
/>
</Target>
</Project>
to use above confiuguration you have to use
MSBuild your.xml /p:Configuration=Release
#Vilx, Check the dependency walker to find out how far it gets. My guess is it would probably stop at vjsnativ.dll. If that's as far as it gets, try this workaround.
Otherwise you'll have to chase down each DLL that the program can't find, and copy them into your program (or its bin) directory.
Its not the compilation problem but the environment problem. The ASP.NET Website will always be built as Any CPU.
However, if you load it on 64 bit machine, by default 64 bit version of IIS is running which
is unable to load COM DLL and it fails.
You need to configure IIS to run 32 bit applications on 64 bit Windows:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis/405f5bb5-87a3-43d2-8138-54b75db73aa1.mspx
You need to use the ASP.NET Compilation Tool (Aspnet_compiler.exe). Look for the ' Finding the Correct Version of Aspnet_compiler.exe' chapter at the end of the doc, it explains how to find the 32 vs 64 bit versions of the tool.
Right-Click on your Web Project in Visual Studio.
Select "Properties".
Click the "Build" tab on the left.
Under "General" change the "Platform Target" to "x86" so it will always build for 32-bit.
Now when you do this you may notice on the same "Build" tab that the "Configuration" is set to "Active (Debug)". You will need to change that drop-down to all the different configuration settings you have (i.e. "Release", "QA", "Staging", "Demo", etc..) and make the same "Platform Target" change to "x86" for each one.
Don't forget to click the "Save" button when you're done - remember to set it back to "Debug" if you're on your development box.
That's probably why it only works when you build it on your machine, and not on the Build Server as the Build Server is most likely set up to build against a different configuration - which is correct, because you shouldn't be using the "Debug" configuration on a Build Server.
Although this is an old question, I was faced with the same problem and I had some troubles finding an answer.
Visual studio offers two options for developing web applications: web sites and web applications. We applications generate assemblies per page, which are dynamically updated if the source changes. On the other hand web application projects are compiled in visual studio to one assembly. This assembly is not automatically rebuilt after changes to the source code. The differences are explained in detail in this document: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
Another difference, which is relevant here is that web application projects allow you to actually choose an architecture contrary to web site projects. Converting a web site to a web application is not very hard, but not too straightforward (the option convert to web application is only available after creating a ... web application). Steps you can take:
Create a new web empty web application
Browse to the directory of new web application and copy all files from your website (overwriting anything in the directory)
Add all files to the project
Right click the project and choose “Convert to web application”.
It may be needed to solve a few namespace issues.