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.
Related
I am trying to do a Visual Studio Build on TFS 2017. So far, it seems to do the build, but will not do the standard Publish/Deploy I am used to on my local file system, with the Precompiled WCF app, etc. This is what I have so far attached as images, and the PublishProfile I have switched to in desperation. They have VS 2017 installed on the build server, and have updated the MS Build to the latest version. Please help! :)
Visual Studio Build
VM Deploy XML
Check the build log to see whether the deployment executed.
Run the MSBuild command locally on the build agent machine to see whether it works.
Try the following arguments:
/p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\" /p:DeployDefaultTarget=WebPublish
While I am building own Visual Studio Extension in TeamCity (same applies to any CI server build that supports building VS solutions), my build stucks on the step DeployVsixExtensionFiles. As far as I understand, the target is defined in VS Extensibility files and is being imported into any .csproj by default. I also realize that this is an "aka test" step that tries to embed an extension into a virtual copy of VS via running a command:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe /RootSuffix Exp /ResetSettings General.vssettings /Embedding /Command File.Exit
I have two questions:
1. Should I disable this step for Release build of Extension?
2. If yes, how can this be done.
The VS SDK installs the extension as a part of a build so you can F5 and run it. If you're CI system doesn't care about that, update your CI configuration to pass /p:DeployExtension=false to MSBuild.
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.
My configuration:
VS2010 solution
TFS 2008
Build server - TFS 2008
Build server also has VS2008 Team Suite and VS2010 ultimate installed
TFS 2008 builds my VS2010 solution properly. But when it comes time to run the unit tests I get the following MsTest error.
Using "TestToolsTask" task from
assembly "D:\Program Files\Microsoft
Visual Studio
9.0\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll".
Task "TestToolsTask" Command:
d:\Program Files\Microsoft Visual
Studio 10.0\Common7\IDE\MSTest.exe
/nologo
/searchpathroot:"D:\Builds\App\Source\86\Binaries"
/resultsfileroot:"D:\Builds\App\Source\86\TestResults"
/testcontainer:"D:\Builds\App\Source\86\Binaries\\Tests.dll"
/publish:"http://tfsServer:8080/"
/publishbuild:"vstfs:///Build/Build/26029"
/teamproject:"Proposal" The
"TestToolsTask" task is using
"MSTest.exe" from "d:\Program
Files\Microsoft Visual Studio
10.0\Common7\IDE\MSTest.exe". No platform specified for publish
operation. For switch syntax, type
"MSTest /help"
MSBUILD : warning MSB6006: "MSTest.exe" exited with code 1.
[D:\Builds\App\Source\86\BuildType\TFSBuild.proj]
The previous error was converted to a
warning because the task was called
with ContinueOnError=true. Build
continuing because "ContinueOnError"
on the task "TestToolsTask" is set to
"true". Done executing task
"TestToolsTask" -- FAILED.
I am not sure what is causing MsTest to fail.
Things tried:
- Provided write access to the build folder to the service account that builds the source on the build machine
You can execute a VS2010 build from within TFS2008's MSBuild, but it looks as if it's using Visual Studio 9.0 TestToolsTask (2008) to try to run a Visual Studio 10.0 (2010) test project (MSTest.exe). I'd try tweaking MSBuild to run the TestToolsTask from the "Microsoft Visual Studio 10.0" folder rather than "9.0", so that the entire process is using the same version of the tools. You can override the tools paths in your tfsbuild.proj file's Properties to ensure the correct version of Visual Studio is used to build with - something similar may apply to the test tools.
Alternatively, it's running the VS2010 test tools correctly, but still trying to use a command line that is specific to 2008 - check the settings and see if you can tweak the command line (you may need to override the MS targets files that is running the build if it's a 2008 version). For example in TFS 2010, a lot of command lines changed from using a simple "server:MyServer" to something like "collection:http://MyServer:8080/tfs/MyCollection". You may therefore have to alter the command line to gain full compatibility with the 2010 version of the tool that is now running, even if it still ultimately points at a 2008 server.
My third suggestion (which isn't necessarily very helpful) is to just upgrade to TFS2010 - it's typically a painless install, vastly better than 2008, and will eliminate any difficulties caused by using a hybrid 2008/2010 setup. (If it helps, I was reluctant to upgrade to 2010 because the 2005->2008 upgrade was 8 days of sheer hell. But in comparison the core of the upgrade to 2010 only took a few hours and "just worked" - the install/upgrade process is much improved)
Jason had the correct idea that lead me down to the correct solution.
In my case, I had to update the "Microsoft.TeamFoundation.Build.targets" to point to "Microsoft.TeamFoundation.Build.ProcessComponents.dll" (VS2010 dll) instead of "Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll" (VS2008 dll)
I also had to make sure that the PlatformToBuild was specified in the TfsBuild.proj file.
Once these 2 steps were done, UnitTests were being run as part of the CI build using TFS2008 and a VS2010 solution.
I have blogged about the solution in detail here: http://blog.aggregatedintelligence.com/2011/03/vs2010-tfs-2008-and-unit-tests.html
For reference, I'm using Visual Studio 2010.
I have a custom build step defined as follows:
if exist "$(TargetDir)"server.dll copy "$(TargetDir)"server.dll "c:\program files (x86)\myapp\server.dll"
This works great on my desktop, which is running 64-bit Windows. However, when I build on my laptop, c:\Program Files (x86)\ doesn't exist because it's running 32-bit Windows. I'd like to put in something that will work between both editions of Windows, since the project files are under version control and it's a real pain to change the paths every time I work on my laptop.
If this were a *nix environment I'd just create a symlink and be done with it. Any ideas?
You can put this in your project file:
<PropertyGroup>
<ProgramFiles32 Condition="Exists('$(PROGRAMFILES) (x86)')">$(PROGRAMFILES) (x86)</ProgramFiles32>
<ProgramFiles32 Condition="$(ProgramFiles32) == ''">$(PROGRAMFILES)</ProgramFiles32>
</PropertyGroup>
And then you can use $(ProgramFiles32) in your post build event.
For more information check this stackoverflow question.