I have an issue building a project in Visual Studio 2010.
I'm not sure why when I build this project it tries to build as Platform="BWS".
I have checked all files in my project and i was unable to find any mention of BWS. It seems that due to this all my referenced projects aren't building.
Also, is it possible to reference other projects within a csproj?
Solution:
It appears that when you are building in VS2010 even though you have Configuration and platform Selected it for some reason still uses System Variable called "Platform" to build dependent csprojects.
To resolve it - I changed my system variable for platform and it resolved the problem.
Thanks #NickCarlson!
I have the same problem. Checking this answer, Why is my Platform environment variable defined as 'BNB'?, I have seen that there is a PLATFORM environment variable pointing to BWS.
Related
I have a (mostly C#) solution that needs to build in x64 because I integrate with a C++ project, so I had to choose a platform.
I noticed that my code changes don't always show up at runtime and I found out that when Solution is Debug x64 it compiles the changed project but does not copy the dll to the bin of the startup project, so the debug session uses an older version of that dll.
I tried most variations of building, and the dll-copy never happens, except when I rebuild the startup project, or the solution, obviously...
When on AnyCpu, all works perfectly all the time. So, alternate solution: maybe I can use the C++ project and keep my C# projects on anycpu?
All projects are enabled in the solution config for both anycpu and x64.
Any suggestions I could look out for?
Because the problematic project was a dependency of a dependency of the startup assembly, I tried adding a direct reference to it from the startup project. The issue disappeared...
Of course, I prefer not having refs that aren't really necessary, so when I removed that new reference again, it kept working. So, now I cannot simulate the issue anymore.
Using git the only change I can see is that the ProjectReference is now a lowercase guid, and it was uppercase... This probably happened when I gave re-referenced the project a try earlier... odd stuff shrug
Heyho,
I'm working my way through Xamarin.Forms right now and today I got the following error when I tried to Release compile the UWP project of my app (Debug is working):
Payload contains two or more files with the same destination path 'System.Runtime.CompilerServices.dll'. Source files:
C:\Users\[...]\.nuget\packages\runtime.win10-x64-aot.microsoft.netcore.universalwindowsplatform\6.2.0-preview1-26926-04\runtimes\win10-x64-aot\lib\uap10.0.15138\System.Runtime.CompilerServices.Unsafe.dll
C:\Users\[...]\.nuget\packages\system.runtime.compilerservices.unsafe\4.5.1\lib\netstandard2.0\System.Runtime.CompilerServices.Unsafe.dll
The projects shared library compiles as netstandard2.0 and again includes a netstandard2.0 library itself, though I don't believe it should be a problem.
The UWP project references "Universal Windows" and the (self-compiled) SQLite.Net library. It also referenced the "Microsoft.NETCore.UniversalWindows" NuGet package, but I uninstalled it (attempting to solve the issue above).
I also tried Cleaning and recompiling the solution, removing and restoring the actual NuGet directories, adding and removing references, up- and downgrading of the UWP packages, changing the build order of my solutions projects...but nothing worked.
Does anyone have any idea what I could do here?
My main problem is that the error seems to come from .NET packages that I can't exchange/remove without crashing the whole project...
Thanks to this question I found a solution to my problem.
Though it wasn't the build target under (Project properties->Build->Build Target) for me I noticed the checkbox "Compile with .NET Native toolchain". I removed the tick and the project compiles fine for Release.
I have inherited a large LOB application that is built using TypeScript. The project has no reference paths in any of the files due to the fact it has been setup and created using Visual Studio 2013 - Visual Studio seems to have some magic where it will pick up the global TypeMaps itself. scoff.
The current build process has been to use Grunt to copy the compiled .js files (which are generated on save in Visual Studio) to a build directory - not actually compile them.
(to further reinforce this point, Grunt is NOT compiling any TypeScript).
This build process is now no longer acceptable as I am moving the application to a build through a Continuous Integration process, using Team City and Command Line tsc.exe/Grunt - so when the repository is checked out there are obviously no generated .js files in the project.
In its current state there is a host of compilation errors when trying to use Command Line tsc.exe/Grunt to compile the TypeScript files, I think due to the fact that the application is not using reference paths?
Does this mean I'm going to need to add all of the relevant reference paths to each file in the project?
Has anyone got any experience regarding this kind of setup and could point me in the right direction to manage these reference paths and build process?
Thanks
In its current state there is a host of compilation errors when trying to use Command Line tsc.exe/Grunt to compile the TypeScript files, I think due to the fact that the application is not using reference paths
No. You should use a tsconfig.json which will create the compilation context.
More
https://basarat.gitbooks.io/typescript/content/docs/project/project.html
A solution has been found.
Using the Visual Studio configuration options in the grunt-ts task I have setup the task to specifically use the projects .csprog and TypeScript 1.4 compiler (we are locked into this compiler).
My configuration for the grunt-ts task:
ts: {
default: {
vs: "Consortium.Client.Web.csproj",
options: {
compiler: "1.4/tsc"
}
}
}
I hope on the off chance, this helps someone else.
MSDN docs Visual Studio Integration (MSBuild) state:
Building Solutions
Within Visual Studio, the solution file and project build ordering are
controlled by Visual Studio itself. When building a solution with
msbuild.exe on the command line, MSBuild parses the solution file and
orders the project builds. In both cases the projects are built
individually in dependency order, and project to project references
are not traversed. In contrast, when individual projects are built
with msbuild.exe, project to project references are traversed.
With my Visual Studio 2010, when building a .sln file with MSBuild from the command line, project to project references are all built, regardless whether they occur in the solution.
What did I miss here? Or are the docs plain wrong?
You are correct that msbuild.exe will sort out all project references whether or not they are part of the solution in contrast to building within Visual Studio 2010/2012/2013/2015 (and possibly later versions) where you will get a build failure if a referenced project is not part of the solution or built beforehand.
In short, yes, the documentation seems a bit off.
You can ignore the build of project to project reference by running msbuild Solution.sln /t:ProjectName /p:BuildProjectReferences=false this explain the sentence in msdn.
I am trying to clean and rebuild a solution file with multiple projects from the command line using MSBUILD. For some reason my build fails (about 10% of the built projects fail) and I get multiple errors which all look like:
error CS0234: The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)
Now if I clean and rebuild the same solution file from Visual Studio 2010 with the exact same configurations it will build successfully with no errors.
Is there a difference in the setup or configuration of MSBuild from Visual Studio that needs to be changed that I am not aware of?
I just had to deal with this issue and it turns out that msbuild likes to move built binaries into the binaries\release directory and reference those instead of the projects themselves when it builds things. After building it copies the files to this directory. This explains why it works in visual studio and not msbuild (I'm currently using TFS 1010).
In my case I had an old binary version of a dll being referenced by a project that was being built after the one that should have generated the correct file. The old one (binary) was overwriting the new one (built from source) as the solution referencing the binary one was being built later in the build.
I assume there's a difference in how the project is built, because Visual Studio does not run MSBuild, as it rather hosts the build engine itself.
This was answered here.
However, I've had similar problem.
In my case the project referenced an external library, which was placed in the project's child directory, unluckily named "packages".
After running MSBuild the folder's content was deleted, supposedly to be downloaded again by Nuget.
The obvious solution was to rename the folder and it worked.
Summary: Set Debug/Release mode in Visual Studio to the same settings as MSBuild to check for compilation errors.
I encountered the same problem:
Tried deleting all "bin" and "obj" folders.
Made sure all related projects are indeed being referenced and not just liked to compiled dlls. ex. Project B references A. Remove A from solution. Then add again. B would then reference A but via compiled dll only. Remove reference and re-add the project.
Finally switched to "Release" in Visual Studio. Turns out I had conditional compilation in some code (eg. #if DEBUG). So what was running in MSBuild and Visual Studio were actually different hence the error "The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)"
Try checking the paths to the references that MSBuild can't find in the non-building library's project file. Sometimes when you use VS or ReSharper to automatically add a reference for you the path ends up being to the \obj directory. VS seems able to cope with this, but MSBuild not so much.
For me the problem was that the some projects in the solution were not included in the build configuration for the solution. Those projects were dependencies for the projects in the build configuration, so all the projects in the solution failed.
After marking the dependcies projects with build in the solution configuration the msbuild ran successfully.
My issue was found in the solution file.
Remove all lines which reference 'ANY' for CPU and leave the 64 bit ones in.
In my case I had one PCL referencing another PCL with different targets. Visual Studio showed me a warning in the references list of the first library, but compiled the solution, whereas MSBUILD refused to compile. I fixed the problem by retargeting the PCL. Hope this helps somebody.
See my answer here.
Basically - Try running msbuild in a new cmd window everytime as a temporary workaround.
I was facing a similar issue. But after spending a lot of time, I finally came up with a solution (that performs similar to VS)
Use the following command to build your solution
"msbuild.exe project.sln /restore /t:Build /p:Configuration="Release";RunCodeAnalysis=False;RestorePackagesConfig=true”