When we are running our build through MSBuild, what context does the MSBuild run in/under?
The reason I am asking is because I have pre-build event that calls a command line program (ajax minification) that works perfectly if the project is build through VS2010 (on the same machine), but does not work when our build system (CCNet) is building it. The error i get is 9009, which means that its cant find the file. The command line program has a environment path set for its location (environment path is set through setx, maybe its only set for current user?), so calling only its name works perfectly in all cases other then when CCNet calls MSBuild.
MSBuild is just like any other development tool, it runs under whatever user context launched it.
When you run msbuild via Visual Studio, it runs as you, because your login context ran Visual Studio, which in turn ran the build.
If you run it through some build service, the answer will depend on how that build service operates. TFS Build, for example, launches MSBuild as whatever user you have configured for the login credentials for the TFS Build service. If you have configured CC.NET to run as a service, then you've also had to specify which user it's running as. That's who MSBuild will also be running as.
If you need a specific environment set up for the build, you have a few options. The easiest one, though very much a "giant hammer" approach, is to globally configure the environment on the build machine for all users. Other options include running some kind of pre-configuration step in your build, or write a startup batch file to launch the service manually after setting up the environment.
Related
I'm trying to set up automated deployment of my application via TFS using the web deploy package publishing method. I've successfully created the build artifact with the appname.zip deploy package in it and an appname.deploy.cmd (generated by visual studio) using a build definition.
However, when attempting to deploy it, it fails to run the cmd file with the error "The specified executable is not a valid application for this OS platform". I have no idea why this might be happening or what I might have missed, especially as this is my first time configuring a build/release definition in TFS. Both visual studio & TFS are 2015 and I'm trying to deploy an ASP .NET application.
The release definition steps are:
1- Copy files from $(System.DefaultWorkingDirectory)/ to F:\WebDeployPackage (runs ok)
2- Run PowerShell F:\WebDeployPackage\App\drop\AppName\obj\Release\appname.deploy.cmd /Y "-setParam:name='IIS Web Application Name',value='AppName'" (Error)
I've checked that the file path is correct & it is present in the same path in the artifacts after the corresponding build. I've also searched for this error but it seems to be very case-specific and I couldn't relate any other answer/google results to my case.
I am not sure if the issue is in my target server or in my release definition or elsewhere, any help appreciated.
I have tested a similar release and worked as expected. So there is nothing wrong with your script or argument:
Maybe the issue is related to deployment environment. You need to go the machine that you want to deploy to and run the powershell command manually ob this machine to see whether it works. Also, you may try deploying to another machine to see whether it works.
Is there a way to auto create a subversion log file when i build my project in visual studio? I'm using AnkhSVN to intergrate SVN into visual studio. I can manually run the svn log command to generate a log file but i'd like to auto create a release notes file every time i build the project.
I'm not familiar with Ankh. However, if you can write a log manually, try writing a batch script that will run the same command, then have VS run the batch file in from the build steps. You can find the build steps in the project properties.
I'm pretty sure this will work. I used the build steps in VS at one time to automatically call an exe that would generate 3D models that would be loaded by the main executable compiled by VS.
Here's a link to msdn that might help:
Specifying Custom Build Steps
Build events might be a better choise, they are in the same vein and there is a "Post-Build event" that is probably when you want to fire your script. I think you can also just run it as a standalone command if you don't want to have to run a batch script.
I have a test project that I want to automate on a test server. For now, I have installed the Visual Studio agents (Test Controller, Test Agent and Test Lab) on my local machine, as I hope to try it out here before touching anything on the test server.
The problem I'm having is that I can't find adequate documentation on automating tests using the Visual Studio agent tools. I have successfully set up and configured the test agent and test controller on my local machine, but I'm not sure where I go from here. The test controller is connected to Team Foundation Server. I have a test project contained within TFS - I want to run the tests within it.
I tried launching the VS test manager and attempted to find a way to run tests from there, but I was unsuccessful.
How do I go about doing this? (in simple steps)
My previous experience is with NUnit, and launching automated tests was as simple is launching the command line NUnit program, providing it with the path of the test project and a few other parameters.
Once the Visual Studio agents are set up and configured correctly, it's simply a matter of running tests against a .testsettings file which is connected to the test controller.
When the tests are run (either via the Visual Studio GUI or the mstest.exe command-line program), the active testsettings file will run the tests on any test agent which is connected to the test controller.
So in terms of automating tests, it's just a matter of specifying the correct testsettings file as one of the command-line switches to the MSTest.exe.
A testsetting file can either be created within the Visual Studio solution or alternatively they can be created within Microsoft Test Manager (automated tests can also be scheduled using the MS Test Manager command-line program, tcm.exe).
To select an active testsetting file to use when running tests from Visual Studio 2010, select the 'Test' menu on the toolbar, then 'Select Active Test Settings'.
We have several web services that we have been deploying "manually" using msdeploy. We pick up the deployment packages from the TFS2010 build machine in the appropriate _PublishedWebsites\<<ProjectName>>_Package directory.
We now want to wrap the deployment packages up with a deployment tool that makes it easier for the person doing the installation to see the parameters.
What we'd like to do is to build the individual web service deployment packages, have the deployment packages land in the right place for the deployment tool build and then have the deployment tool build both build the tool and copy the previously-built deployment packages to the same Binaries drop folder on the build machine.
For some reason, this seems incredibly difficult to do.
Things we've tried
Setting Location where package will be created on the web services project's Package/Publish Web project settings using a variable (e.g. $(TargetDir)). Visual Studio interprets the entered variable and replaces it with the hard-coded path for the development machine... and that's what goes to the build machine. On the build machine the end result is... nothing; the deployment packages are still sent to _PublishedWebsites\<<ProjectName>>_Package.
Setting /p:PackageLocation on as one of the MSBuild Arguments settings on the TFS build definition "Process" / "Advances" section, in addition to /p:CreatePackageOnPublish=true /p:DeployOnBuild=true. All this did was generate the error:
MSB1008: Only one project can be specified. Switch: p:PackageLocation=$(BinariesRoot)\DeploymentFiles For switch syntax, type "MSBuild /help"
presumably because there is more than one deployment package being generated by the build.
Any advice appreciated! Are we going about this the wrong way? Should we be doing something like altering the build XAML to cater for this (like this page suggests for another issue)?
Couple possibilities for you to consider:
1 - Alter the TFS workflow like you've described to perform some copy task
2 - Create an MSBuild project that runs after your standard Packaging steps to copy the output from _PublishedWebsites to some location of your choice
3 - Override the following MSBuild parameter when building the package to change the package drop location:
<DefaultPackageOutputDir Condition="'$(DefaultPackageOutputDir)'==''">$(OutDir)[YourDesiredLocation]\$(DefaultMSDeployDestinationApplicationName)\Package</DefaultPackageOutputDir>
Note that you can see the set of packaging MSBuild parameters available to you at
c:\program files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
I recently implemented suggestion #2 at a client, using the MSBuild overrides suggested in #3 in the custom MSBuild project file and it worked like a charm.
In the project I've inherited, the original developer used a number of post-build events in his Visual Studio projects to copy around DLL's and stuff when building inside VS.
This is causing some grief now that I'm trying to move these things to the TFS 2010 Build system.
I was hoping to be able to create a new "Continuous" project configuration, and exclude those post-build events from Visual Studio in that configuration - but it seems those calls aren't configurable based on your project configuration....
Any ideas? Is there something I could check for to know I'm running under TFS Build and then just skip those CMD files? Any ideas would be most welcome!
My approach is to guard the pre- or post-build code with this
IF "$(BuildingInsideVisualStudio)"=="true" (
…your code here…
)
That variable is automatically defined by Visual Studio and you do not need to change the build definition.
I use a similar approach to do this. I add the following to each project's post-build steps:
if '$(TeamBuild)'=='True' exit 0
Then when configuring the Build Definition I simply add:
/p:TeamBuild=True
...to the MSBuild Arguments.
This gives me the flexibility to keep all the configuration in the projects and the build definition.
What if you set an environment variable on your team build server, and then you could write a check into your post build steps to check for that environment variable. If the environment variable is set, you'd know to skip the command files that do the post build steps because you'd know you are running under TFS build.
You could combine all your post build steps into one script possibly, and then just check the environment variable at the beginning of that script.
Or you may be able to do it the opposite way and build the check into your TFS build script. You can refer here for how to check an environment variable in a TFS build.
So in your TFS build script you'd have something like:
<RunScripts Condition=" '$(RunScriptsServerVar)' != '' ">
the environment var is NOT set, so run your scripts since we aren't in
a TFS build
</RunScripts>