Lately we (the team I work with and myself) have been seeing something strange between the build results of MS-build and Visual Studio (2015).
The situation
The team I work with has been tasked with refactoring an older and rather large c# project that contains many (150+) projects all bundled into a single sln file. As to be expected merge conflicts occur in the sln file during our work and one of the team members resolved this conflict incorrectly. Leaving the sln file with a missing project reference.
From here on out the behavior of the project is different on 3 location. They are described below
Visual studio of the developer that origionally made the mistake
(note that I assume that this developer has not cleaned his solution)
This programmer has already build and run the project (using visual studio 2015 professional). So all compiled dll files are in the prorammers output folder. This means that Visual studio does not notice that a reference is missing. The programmer can build, run and test the application without any problems.
The build server
The build server (Jenkins) does not run Visual studio, but it uses MS-build 14 to compile the source code. The Jenkins server is configured to run with pipelines, described in groovy. We call ms build by invoking a bat script that runs MS-build over the command line. An example:
"C:\Program Files (x86)\MSBuild\14.0\Bin\amd64\msbuild.exe" "TheSolutionFile.sln" /property:Configuration="Debug" /property:Platform="Any CPU"
Somehow the build will succeed even with the incorrect sln file. I suspect that ms build resolves its own dependencies as the workspace on the buildserver is clean (completely empty) so no leftover dll's can fool the system. (am I correct in assuming this?)
The other team members
The other team members will eventually pull the changes of the broken sln file and they will be in for some 'fun'. When you do not have the dll files in your output folder Visual studio will attempt to rebuild the missing dependencies. But since the references cannot be resolved it will fail and start stacking errors about missing meta data. In the team we all use Visual studio 2015. But we also tried it with 2017 and ran into the same result. The person who originally made the mistake can also end up in this group of he cleans the solution.
The Question
Obviously we are not happy with the fact that the build server accepts the build with a broken sln file (a developer pulling the latest version cannot compile or run the program). Is there a way to get the last two situations in sync (so ms build not accepting a 'broken' sln file to compile)
Is there a way to get the last two situations in sync (so ms build not accepting a 'broken' sln file to compile
That is because MSBuild.exe from command line does not have the same build environment as Visual Studio. You can call MSBuild.exe from VS command promt which has the same biuld environment as Visual Studio.
If you want call ms build by invoking a bat script that runs MS-build over the command line, you can use devenv.exe to build the solution/project from command line:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE>devenv "D:\TestSample\TestProject\TestProject\TestProject.sln" /build Debug /project "TestProject\TestProject.csproj" /projectconfig Debug
For the detail information about devenv.exe you can refer to Devenv Command Line.
Hope this can help you.
My advice:
The .sln file is just a collection of project files. Create a brand new one, and add in your proj files one by one. Forget the code-merge-conflict-resolution drama.
The voodoo in the .sln file is too much voodoo. Let VS do it for you...as you add each project in, one by one.
File / New / Project ::: Installed / Templates / Other Project Types / Visual Studio Solution ::: Blank
Solution.
One other hint. If you still have issues, then open up each proj, and any "by project" references, delete them and re-add them. Sometimes the GUID's get mixed up, especially over a long code-merge history.
Related
I have a large solution of dozens of projects. Since yesterday (and for no good reason that I can find) the projects are refusing to build, with Visual Studio's build output window simply stating (eg)
1>------ Skipped Rebuild All: Project: Api.Models.Common ------
There are already a few similar q/a's here about the reasons why VS may decide to skip a build (Configuration not set to build, or set to build wrong target). I'm not interested in guesses as to why this isn't building. I'd really like answers to help me diagnose this, and have Visual Studio tell me why it thinks it can skip the build.
Is there a way to have VS generate anything more detailed than Skipped rebuild for example? It must be calling msbuild under the covers right? So can I have Visual Studio pass additional parameters to msbuild so that it generates diagnostic log output?
(For what it's worth - calling msbuild from the command line builds the projects as expected, so it seems like my issue is something quirky that VS is doing).
I'm using VS 2017 - 15.9.4
If you have any unload projects, you must load it or you remove it in solution.
Note: My unloaded project was the result of a permission issue. VS warned that a project was configured to use IIS. To run the project with IIS required launching VS as an administrator.
This was happening in my solution with Visual Studio 2019. I just migrated my applications from .Net Framework 4.6 to .NET5, almost all the projects were not building, it gets always skipped. The reason was that after the migration the tool upgrade assistant was not setting the Target Framwework as in the preceding image (Right-click on the project and then click on Properties).
After setting it to the right framework, in my case, it was .NET 5.0, the project started to build.
We are in the process of upgrading our TFS 2013 server to TFS 2015. In that regard I have run into an issue when trying to perform an application build on a build agent with the new version, using our XAML template build script (which was created in TFS 2013).
Most of our solutions use the above-mentioned template when we build them. The solutions (sadly, still) use setup projects (.vdproj) to generate an MSI package for the application. To build the setup project, and produce an MSI, for a given application; we call the devenv.exe (in our case, it points to Visual Studio 2013) in our template build script:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe /Build "Release|Any CPU" "d:\<path_to_solution>\solution.sln" /Out c:\temp\out.log
However, on our new build agent no MSI is produced, and calling devenv.exe yields neither any output, nor any error messages. If I try to call devenv.com, however, it starts building, but still no MSI is being produced.
When things start to build using devenv.com It seems like it is completely disregarding the setup project (I have checked the build configurations, and the setup project is checked for build on the "Release|Any CPU" configuration).
I have looked at build logs, build process activity logs, and I have also tried to perform the steps manually on the build agent, but I haven't been able to find anything that could point me in the direction as to what might be causing the issue.
Does anyone have an idea what could be the reason for this? Could it be an issue with TFS Build 2015? The only difference between the old setup, and the new - as far as I can tell - is the following:
VS 2013 was installed on C: rather than D: on the new build agent, i.e. the path to devenv would be different, but that should not matter as long as the build script is looking in the right place, and finds it...
We use a different drop location than what we used for the old setup
Appreciate any help and suggestions I can get.
Problem solved, and everything is now building successfully. I did not do a good enough job of looking at the diff between the setup we had on the build agent we used for TFS Build 2013 vs. the one we set up for TFS Build 2015.
Firstly, to be able to build setup projects in VS 2013, one needs to install the Visual Studio 2013 Installer Projects extension on the build agent.
However, there are some bugs with this extension that often causes building setup projects to yield the following error message: "An error occurred while validating. HRESULT = '8000000A'". This error can be fixed by modifying the registry, as described in this SO post.
Building the setup projects using devenv.exe, however, still doesn't work. I have not been able to figure out why, yet.
Use the Vnext build in TFS 2015 to build .vdproj. You just need to add one additional build step i.e "command line" then call devenv.com to build.
Such that,
tool :
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.com
arguments :
HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj /build release
This will help you.
I am working with Microsoft Visual Studio and have a problem when opening a solution file. The solution file consists of a core project and multiple plugin projects. During development, there may be instances where every plugin project is not extracted with the core.
When opening this solution file during development, Visual Studio will complain about missing plugin projects and will have a separate pop-up window for each missing project. Is there some setting in Visual Studio to turn off this warning? Ideally, I do not want to have multiple instances of the solution file or create a script to modify the solution file every time a new project is extracted from our repository. I looked through all of the settings and could not find a flag or warning to turn off.
You might have build the project in the previous version (i.e 2008) and trying to open in the newer version (i.e 2010).
For two of my VS 2005 C++ projects, VS wants to write to the .sln file when I build the projects. I have got a number of other VS 2005 C++ projects where this is not the case. It is a problem as due to the fact that we have ClearCase source control integrated with our VS 2005 installations and when we try and run an overnight build via batch files, the build pauses as a ClearCase check out dialog box is displayed.
Looking at what VS is changing in the .sln files, it is the second GUID on the project line.
Before building:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{A2AF232A-7F27-4340-81D5-8ABFD10994D2}"
After building:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{67BE85B7-3234-484E-88FB-4F0E42096583}"
Any help gratefully received. I am new to VS 2005, as we have only recently migrated from VC++ 6.0, so apologies if I have missed something obvious.
We are running VS 2005 Professional Edition, with SP1 installed.
Regards,
Greg.
I had similar problem. It seems that when converting projects from old versions of VS (like 6 or 2003) VS 2010 is not adding Project GUID to the .vcxproj file. Because of that when you open solution including such project VS will recreate GUID for such project, and will change .sln file but will not change .vcxproj file. So another time you open such solution the situation will be the same and the .sln file may change again.
See this: http://connect.microsoft.com/VisualStudio/feedback/details/586258/missing-projectguid-in-vcxproj-files
I am guessing here, but it looks like some changes have been made to the InterCommClientB project(project, not the files in the project). When this happens the sln is updated, in this case only the project GUID.
My best guess to resolve this issue would be to manually build the solution and then checkin the changes. This way the sln file won't change on build.
My second best guess is that you already made this changes at your computer and it is working fine, but you did not get lattest version on the pc where you do the night build .
This might be totally out there - but sometimes Visual Studio fails to check-in a Solution file when it's been modified and while the Solution is open in Visual Studio. Try closing Visual Studio, and only then committing the Solution file.
If it isn't that, there might be some other agency causing the Solution file to need to change the GUIDs its using. In one instance, I was using .NET tools from National Instruments, and they has a licensing scheme that would trigger that sort of action (modification of extraneous files for not good reason) whenever I went to do a rebuild.
Please take a careful look at the output from the build (in the log, or the output window) - you may find some further clues there!
I'm working on a tool to simplify an application's deployment. Hence I'm aiming to automate the build of the setup project.
The Situation:
When I use Visual Studio to build the setup project this, creates the msi and exe files and concludes successfully. The problem occurs when I run a command in the command prompt, I keep getting this error "ERROR: Cannot find outputs of project output group '(unable to determine name)'"
The command for the command prompt is:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE>devenv "C:\Project's Directory\Project.Setup.vdproj" /Build
Can anyone help me with it.
I'm really stuck.
EDIT: The solution to my problem was to create a solution which contains the setup project and the project which is actually the output project of the setup project.
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE>devenv "C:\Project's Directory\Project.Setup.sln" /Build
Thanks to everyone.
You can't do this.
The issue is that you have defined your inputs to the setup project as outputs from the other projects in the solution. You have to build the entire solution to use this method.
You can do this but you have to manually link all the files you want into your setup project. It is a bit more tricky but just as doable.
I suspect that you have a setup project that is referencing the output of another project. in this case you need to use
devenv [solutionname] /build
the reason you are getting the error is because visual studio has not compiled the referenced project.
side note: if you are trying to automate a build in vs 2005 or later I would investigate wix as it is easier to automate using msbuild.