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.
Related
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 contributing to a fairly large project that uses MSBuild properties to control the build process. I am running some tests from the command line like this:
msbuild /p:Configuration=Release /p:OSGroup=Windows_NT /p:Performance=true
And everything is working fine. However, when I try to run the tests from Visual Studio, the OSGroup and Performance properties are not set, which causes things to not work correctly.
Any idea how I can set these properties before building my .csproj file within Visual Studio? It has to be without editing the .csproj file, since I don't to accidentally check in any changes I make there. Thanks in advance.
You could just add an external tool command which builds using the same command as shown. VS will parse the output just like from it's own builds, so warnings and errors are shown in the Error List etc. Your command would be something like
msbuild $(SolutionDir)$(SolutionFileName) /p:Configuration=Release /p:OSGroup=Windows_NT /p:Performance=true
You can implement a Visual Studio extension and access project properties trough DTE.Solution.Projects and Project.Properties. There is an example here:
https://msdn.microsoft.com/en-us/library/bb166172.aspx
VS DTE interface can also be used in a standalone application or Powershell script.
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.
Generally, we use Visual Studio to build solutions in release mode, and after the build some files get copied to different locations.
Is it posible to know what the exact command line is that is being used by Visual Studio? I want to use that same command line and run it from a batch file, ensuring that my solution gets built the same way that it would inside of Visual Studio.
Note: I know how to build solutions from a batch file. Its just that I want to know what my current Visual Studio 2010 configuration is using to build the solution.
I've got a project that used to work in VS 2008 that has a custom build tool for each file (runs a batch file) that used to work as expected.
On upgrading to VS 2010 when you build the project it only builds one of the source files, then stops without errors.
If I compile each file individually they work fine. If I repeatedly build the project it builds each source file in turn until they are all done.
I suspected the conversion process so re-created the project from scratch and it had the same issue..
any ideas?
Thanks
Trev
Apparently, this is by design in Visual Studio 2010:
http://connect.microsoft.com/VisualStudio/feedback/details/572435/only-1-custom-build-step-is-executed-in-a-build
There is a little more discussion here:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/3de31464-46fb-40a3-a666-496355b1b6be/
I'd love to have a work around for this.