I have to use a Pre-Build event in Visual Studio in order to either copy a file from template version to compilable version, or to call a tool to translate the file - depending if I am in Debug or in Release mode.
As found here before, I used the debug switch
if $(ConfigurationName) == Debug goto :debug
$(SolutionDir)\Tools\MyTool\Translate -i $(ProjectDir)\Themes\Generic.Template.xaml -o $(ProjectDir)\Themes\Generic.xaml
goto :end
:debug
copy /y $(ProjectDir)\Themes\Generic.Template.xaml $(ProjectDir)\Themes\Generic.xaml
:end
Everything works fine, as long as I use my local Visual Studio. But when building with TeamCity, the Studio macro variables are not set correctly. Visual Studio itself is not installed on the build server. As build script we use f#make, which calls msbuild with the solution file. Calling the build batch locally also runs perfectly, so it seems that TeamCity hides these vars somehow.
Are there any known issues about that?
I do know that there are distinct differences between msbuild and devenv.exe when building against a .sln file. For example, msbuild driven builds will not build Visual Studio deployment projects. I can't say for sure what the effects are within prebuild steps.
I recommend changing your TeamCity build step to use devenv.exe instead of msbuild (probably will need a command line build step) and just see if it works better.
TeamCity provides some built build parameters that can help you find the correct path to devenv.exe on your agent(s). They are env.VS100COMNTOOLS and VS2010_Path.
Related
I'm trying to use the msbuild to build visual studio project using command line.
I used this commands
SET VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120
msbuild.exe ../../../embedded/ports/visualC12/config-from-host.vcxproj
/p:Configuration=Release /p:Platform=Win32 /t:rebuild
Using IDE : it took around 2 min
Using cmdline: it took around 20 min
In command line it looks like it build a lot of projects that are not built in the IDE
Any suggestions?
In command line it looks like it build a lot of projects that are not built in the IDE Any suggestions?
That because you are using the property /t:rebuild in your command.
This switch performs the same function as the Rebuild Solution menu command within the integrated development environment (IDE)-will clean and then build the solution from scratch, ignoring anything it's done before. So MSBuild will build all projects regardless of whether them were built before or not.
When you build projects in IDE with build option ranther than Rebuild, it will perform an incremental build: if it doesn't think it needs to rebuild a project, it won't. It may also use partially-built bits of the project if they haven't changed. That is the reason for a lot of projects build in command line but are not built in the IDE.
To make the build faster, you can change the property to /t:build in command line or select rebuild option when you build in IDE.
Besides, there are many factors that affect the speed of building, for example, parallel. When we build multiple projects in IDE, the default value of parallel is 8, Tools->options->Projects and Solutions->Build and Run:
MSBuild command line is also support parallel, /maxcpucount Switch
msbuild.exe myproj.proj /maxcpucount:3
So when you compare the build speed between the command line and the IDE, you have to make sure that all the relevant settings are the same for command line and IDE.
Hope this helps.
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 have this command in a post build event:
if $(ConfigurationName) == Release "$(SolutionDir)Tools\NuGet.exe" pack "$(ProjectDir)MyProject.Contracts.nuspec"
This works just fine when I compile in Visual Studio. But when my build runs this it fails. That is because someone somewhere thought it was a good idea to have builds on TFS not run the same as a build on a dev machine.
In this case it is the fact that all output files are grouped into a common "Binaries" folder.
So, my question is this:
Is there a property I can use (instead of ProjectDir) that will allow me to reference the output location of the build?
Meaning that it will point to the binaries folder when running a TFS build and point to my normal output when doing a normal Visual Studio based build.
I tried $(OutDir) but it equated to "bin\Release\"
UPDATE: I tried to use $(OutDir) but Visual Studio fails with the partial path it provides. Is there something that could be used with $(OutDir) to give a full path for both Visual Studio and TFS builds?
In case it matters:
TFS version is TFS 2010 (Latest releases installed)
Build Machine and Dev Machine are both running Windows 7 and VS 2010 Ulitmate
$(OutDir) should resolve to your bin\debug or bin\release etc for local builds, on the build server this will be resolved to the Binaries folder.
So yes, $(OutDir) should be the right one to use.
In VS 2008 and VS 2010, one can easily create a solution and modify the "Solution Configuration". We can choose what configuration each project gets built in when we trigger a build at the solution level.
Is such a facility available in the Visual Studio 6.0?
In my experience:
when a configuration is chosen (form the list available) in VS6 for a VC++ project, the dependencies (which themselves have multiple configurations defined) get built in some random order. There is no way to control the configurations of dependencies at build time.
"Batch Build" does come close to this but is not as flexible for my purpose.
I have tried various options in the VS6.
Hope I am clear.
Here is a link on the MSDEV command line.
https://msdn.microsoft.com/en-us/library/aa699274(v=vs.60).aspx
There is a way to control the building of dependencies. Specify /NORECURSE and dependencies will not be built.
I use /REBUILD with /NORECURSE to keep the dependencies from getting built.
And I build each project one at a time inside the workspace in a bat file by doing a chdir to the subdirectory and calling MSDEV just for that subproject:
msdev myproject.dsp /MAKE "myproject - Win32 Debug" /REBUILD /NORECURSE > Build.log
Then I cd to the next project directory one at a time.
On a side note, I had difficulties for several years where NMAKE would not work for my specific tasks. Turns out that the PATH environment variable inside MSDEV (Visual Studio 6.0) is different from the PATH environment variable of a command shell you would run NMAKE on.
The Path used by the MSDEV shell is the %PATH% at the time Visual Studio 6 was installed. We use this and poke the registry as needed for MSDEV to get the correct path setup when switching revisions of our software; however this doesn't help update the %PATH%. The MSDEV path can be queried with a query script. I don't have my example handy.
That is why builds in MSDEV sometimes work when builds using the command line don't, as the path to DLLs differ, and any custom build steps that run .exe will not work outside of the MSDEV environment unless the path is updated.
I have a script somewhere that reads the queries the registry to extract the MSDEV path and update PATH of a shell so that batch scripts doing nmake will work as they would inside the MSDEV shell environment. The problem with the REGISTRY QUERY is that the return arguments differ with different flavors of Windows (XP/SERVER2003/...).
One thing I just discovered is that Incredibuild works with the old VS6.0 MSDEV IDE. This is a game changer. It distributes builds. I'm evaluating it now, but it might be useful to anyone waiting for long VS6.0 builds.
Under vs10 msbuild.exe how can a specific project within a solution.sln be Ignored?
I am building a large project that is moving to Visual Studio 10.0. In the IDE I can uncheck a project within the configuration manager and it will not build it. I need to mimic that behavior with a command line call to msbuild.exe.
The project I want to bypass is an *.dll plugin with a link error. I am stuck on stupid with the link error at the moment and since it stands alone, I can run the main program with out it and just live with a warning at run time that it isn't present.
I need some switch magic concerning calls to msbuild.exe.
If you have a certain configuration in the sln (configured in VS Configuration Manager) that you want to build with MSBuild, you can do so with the following command line:
msbuild /p:Configuration=MyConfiguration MySolution.sln