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.
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.
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.
I'm having a problem when trying to build my project and i don't know where to look.
The problem is that the build fails every time. it gives me the following error
Error messages on build
When I searched for those files I found that they weren't in that folder
The strangest thing is that if i build the same project on the visual studio, or if I run MSBuild from Visual Studio 2010 command line the project builds without problem. Also, I have configured another builder in another computer, and when I run the build there with the same Build definition it builds correctly. My guess is that it have to be some configuration that i'm missing, but I don't know where to look.
The computer is running Windows Server 2012
I have the following error on the build server for code that compiles and passes tests fine locally.
(150): The imported project
"C:\Program
Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path
in the declaration is
correct, and that the file exists on
disk.
I've added the WebApplications folder from my local machine to the appropriate path on the build server but I'm still getting the same error on build.
I believe the recommended approach with TFS2008 was to install VS2008 in it's entirety on the build server. Is this still the case with TFS2010 and VS2010 accordingly? a.k.a Sledgehammer to crack a nut.
Pretty much, especially if you plan on using other features like MSTest. You can try just adding the targets file but you'll probably still have some missing dependencies. You could go through the whole process of fixing the dependencies as you go along but it's probably easier just to install VS 2010 and be done with it.
This blog post seems to describe a way to do what you want without having to install additional software on the build server, if all you need is the .net compilers. It does not cover C++ compiler setup.
I discovered that if you're going to do just "standard" (i realize that's open to interpretation) web apps and non-web apps (e.g. services), you can get away with installing just Visual Studio 2010 Shell, plus Visual Studio 2010 SP1 on the build server. That will get you the missing .targets files.
Since a full VS install is required for advanced features, does anyone know if the build-server-install license cost is waived?
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.