I'm running a msbuild batch command in order to build my solution and i'm getting: error CS0246: The type or namespace name '******' could not be found (are you missing a using directive or an assembly reference?)
This is the batch command:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe %~dp0****.sln /t:clean /t:reBuild /v:d /m:4 /p:Configuration=Debug /p:Platform="x86"
But when i'm running a build for the same solution from within the visual studio everything works fine.
I checked project dependencies and everything looks fine, the same problem happens when i'm running TFS build with the build definition I had built for this solution.
I'm building with Visual Studio 2013.
Any idea?
Apparently by removing the parameter /p:Platform="x86" the problem was solved, I have no idea why it crashed the build, might be because the solution configuration was already on x86.. could be a bug in MSBuild?
Related
I'm trying to upgrade our build process to use MSBuild 15.0 that comes with VS2017. Up to now we've been using MSBuild 14.0.
When I use MSBuild 15, I get this error.
C:\Program Files (x86)\MSBuild\Xamarin\Xamarin.Android.Sdk.props(16,3): error MSB4184:
The expression "[System.IO.File]::ReadAllText(C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\devenv.isolation.ini)" cannot be evaluated.
Could not find file 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\devenv.isolation.ini'
It looks like $(VsInstallRoot) which is used by the props file is pointing to the wrong location.
Does anyone have any ideas about what might be going on or how to resolve this problem?
Thanks.
Turned out to be loser error, for part of the problem anyway. I'd installed MSBuild standalone tools and was trying to use that hence the VsInstallRoot problem.
In my case helped to uninstall separate MSBuild installation. I use MSBuild only in Visual Studio and through gradle plugin.
I use syntax like "%SDK_PATH%\sdk_dir\test.vcxproj" in .sln file.
And it is work fine for me from IDE.
But msbuildl does not understand this syntax and will emit a error MSB3202 ("The project file was not found.") when I use it from command line:
msbuild test.sln /p:Configuration=Debug
Is there a way to resolve this issue?
I have a solution that contains a project with AutoGenerateBindingRedirects set to "true". When I build it via Visual Studio 2013, the .config file in the output directory contains an generated assembly binding redirect for EntityFramework, and the project runs. However, on the build server, which calls MSBuild, this property is not followed, which causes the project to fail to start. Does anyone have any idea on why there might be differences in the build results between the two methods?
For reference, the build server is executing a command like
MSBuild MySolution.sln /p:Configuration=Release,DefineConstants="SOMETHING" /t:Rebuild /tv:4.0
I get the same results when invoking this on my development machine, too, so it seems to be a peculiarity with MSBuild and/or Visual Studio. I've tried variations like
MSBuild MySolution.sln /p:Configuration=Release,DefineConstants="SOMETHING",AutoGenerateBindingRedirects=true /t:Rebuild /tv:4.0
to no avail.
I'm trying to build V8 as part of ArangoDB using the official build scripts and following the official Windows build instructions.
The compilation fails for all v8* targets (v8-build.bat):
msbuild All.sln /t:v8 /p:Configuration=Release /p:Platform=x64
msbuild All.sln /t:v8_libbase /p:Configuration=Release /p:Platform=x64
msbuild All.sln /t:v8_libplatform /p:Configuration=Release /p:Platform=x64
error MSB4057: The target "v8" does not exist in the project.
If I open the solution file in Visual Studio, it looks like this:
I can build v8, v8_libbase and v8_libplatform just fine in VS.
Windows 7 64bit
Visual Studio 2013 Ultimate
Cygwin 2.2.0
cmake 3.3.1
You can run
set MSBuildEmitSolution=1
msbuild All.sln /t:v8
Then search in the generated All.sln.metaproj file the exact target names (<Target Name="">) of all projects you want to build. v8 can have a name like _tools_\_gyp_\v8. After that you can build projects
msbuild All.sln /t:"_tools_\_gyp_\v8" /p:Configuration=Release /p:Platform=x64
The correct way to specify a target/project if it's in a solution folder is:
msbuild all.sln /t:PATH\TO\PROJECT
But in case of (tools) and (gyp) it's simply not possible, because msbuild can't handle parentheses in the target parameter /t.
So either remove ( ) and specify the path like tools\gyp\v8, or get rid of the solution folders entirely. If the solution is flat, /t:v8 will work.
Unfortunately, both the wrapping of folder names with brackets as well as the generation of non-flat .sln are hardcoded in gyp, which generated my all.sln. There is no switch to control whether solution folders are created or not. It will create them if the target version of Visual Studio is known to support this kind of nesting.
Workaround: Force flat solution generation in gyp, see
https://github.com/arangodb/arangodb/commit/796d2d263db6271142d954c8c99b9dec0fbe75e9
Reported errors to Microsoft/msbuild and Google/gyp:
https://github.com/Microsoft/msbuild/issues/157
https://code.google.com/p/gyp/issues/detail?id=494
#dothebart and this post helped me a lot to figure it out, thank you!
In VS2013 use
msbuild All.sln /p:Project=v8;Configuration=Release;Platform=x64
I've recently upgraded to Visual Studio 2013, which has caused back to back problems when building externally using MSBuild (API or Executable with command line args)
Issue #1
When building with MSBuild it doesn't generate Fake assemblies which are required for our Unit Tests, this leads to build failures. A simple build in visual studio fixes this temporarily, until a new fake assembly needs to be generated.
Issue #2
When running code analysis this complains with the following:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(284,5):
error MSB4127: The "CodeAnalysis" task could not be instantiated from the assembly "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\.\FxCopTask.dll".
Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Build.Tasks.CodeAnalysis' to type 'Microsoft.Build.Framework.ITask'.
I only have Visual Studio 2013 installed on my machine, apparently installing an older version could fix the issue, but it's not something which I can do. (VS 2013 Ships with its own MSBuild 12.0 which is located in a different directory to the previous MSBuild).
I'm unsure why Visual Studio is behaving any differently to MSBuild, i'm simply pointing to the solution file like so...
msbuild.exe "path\solution.sln" /property:Configuration=Debug
So, Visual Studio 2013 comes with a new version of MSBuild i.e. MSBuild 12.0. Once installed, it changes the path so that the new version is used by default.
Looks like your solution compiles with visual studio 2012, you can either specify the full path to msbuild.exe such as
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild "path\solution.sln" /property:Configuration=Debug
or set the visual studio 2012 environment variables by running the following before executing msbuild
"%VS110COMNTOOLS%"\vsvars32.bat // VS2012 environment variables
EDIT: Using MSbuild 12.0 assemblies "C:\Program Files (x86)\MSBuild\12.0\Bin\" fixes the issue with the code Analysis bug.