I'm attempting to use the VS2010 command line utility, devenv.exe, to deploy a web solution, eventually on a bamboo CI server. The problem is, when I use the /deploy parameter, the solution builds, but does not deploy.
I've tried different parameter sets. I've included the /project setting to deploy a single web project, and tried it without. I've tried different configuration names (debug, release) to no avail.
I'd appreciate any help I can get on this.
Thanks!
I found the answer. The command line utility aspnet_compiler can be used to deploy a web application. Apparently, it's what the IDE calls when you trigger a web deployment.
Related
I am trying to deploy an web application that was created on VB with the .NET Framework 2.0 using the TFS 2017 continuous deploy. It doesn’t have a solution file inside like vbproj or csproj, so I needed to avoid all the suggestions to include extra information on the vbproj.In order to run the MSBuild even locally I need to change in my .sln this tag, so all my compiled code is also there
Debug.AspNetCompiler.TargetPath = "....\PrecompiledWeb\ARB\Debug\"
Unfortunately, I can’t deploy the application using the TFS. So far I tried to deploy it through my Visual Studio project, and is working fine with every option: I tried MSDeploy, Web Deploy Package, and FileSystem, and is working fine from the Visual Studio Publish Option
With that, even my transformation take place.
Now lets say I go to my TFS and I put this parameters on the MSBuild
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsASingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="\\MyServer\Content"
My files are compiled but never stored in my Content folder. No one of them!!! I can’t figure out what is going on here.
From your screenshot, you are using a Web Site project, not a Web Application project. The output structure of a Web Site project in TFS is different from build in VS (you can see a PrecompiledWeb folder in your build source directory on build agent server). Instead of using MSBuild argument, you can consider add tasks below to copy the files you want to publish:
We strongly suggest you switch from Web Site projects to Web Application projects to avoid these issues.
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.
First post on Stack, so please be gentle!
We are just getting into Continuous Integration with TeamCity. We have setup a TeamCity project(s) that looks like so:
Solution Build (builds entire solution) - .Sln file
Debug to Dev Server (builds .csproj in Debug configuration and Deploys to test server using MSDeploy)
Release to Production (builds .csproj in Release configuration and Deploys to production server using MSDeploy)
Within our Umbraco Visual Studio project (which is a Web Application not the standard Website project type) we have the umbraco_client and umbraco folders excluded from the Project, primarily because they are already compiled and don't need to be re-compiled by our process. Both folders are however included in the SVN repo.
The problem we are experiencing is that because these two folders are excluded from the Visual Studio project, TeamCity does not deploy them.
So my question boils down to "how do you include folders in the TeamCity build package where the folders are in the SVN but excluded from the Visual Studio project?".
Any pointers would be really appreciated.
Thanks
dotdev
We've been using TeamCity for umbraco. This is what we've been doing recently on our internal dev servers:
/p:Configuration=Debug
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=OurDevServer/msdeployagentservice
/p:AllowUntrustedCertificate=True
/p:MSDeployPublishMethod=RemoteAgent
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=umbraco_site
/p:IgnoreDeployManagedRuntimeVersion=True
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
/p:SkipExtraFilesOnServer=True
/p:ExcludeFoldersFromDeployment="media;App_Data\Logs;App_Data\preview"
/p:IncludeSetAclProviderOnDestination=False
/p:AuthType=NTML /p:UserName=
They key to solving the problem you are having is
/p:FilesToIncludeForPublish=AllFilesInProjectFolder
By default, it is set to something like "AllFilesInProject". Combining FilesToIncludeForPublish with the ExcludeFoldersFromDeployment can give you some control over exactly what TeamCity attempts to deploy
I would suggest using an approach similar to the one described in this blog post: http://blog.iqit.dk/2013/11/using-package-restore-in-umbraco-projects
You don't mention nuget, so assuming you use a zip or web pi to setup Umbraco in your solution, but you should still be able to use the targets listed in msbuild or add to your web applications .csproj when building your solution. It would require that you have the Umbraco and Umbraco_client folders somewhere in Svn repo or on your build server in order to copy it in.
As an alternative I can also recommend that you download the UmbracoCms nuget as that contains an extension to the msdeploy pipeline that includes the two mentioned folders in an msdeploy zip package. But again also based on the nuget install and thus a standard location for the Umbraco folders.
Hope this helps.
I've based my TeamCity builds on Troy Hunt's excellent "You're Deploying it Wrong" series - which is an excellent step by step guide to integrating Visual Studio based projects and TeamCity. http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
As to excluding the umbraco and umbraco_client folders from SVN; a complex Umbraco build will probably have changes in the Umbraco folder to the default build eg adding Umbraco Event Handlers, adding new Umbraco Sections, changes to back-office tabs. I don't think umbraco_client will change unless you get into changing rich text editors and so on - but it is possible. So I'm not sure that excluding those particular folders is correct. Excluding the media folder is often discussed as well - but it does make TeamCity config simpler if everything is there.
But to answer your question you could exclude them from the build and copy them onto your build server; then add a 'Command Line' runner build step that simply copies them back into place before the build step starts.
I usually add a source control change step that fires a rebuild and have two build steps in TeamCity for an Umbraco project. One is a 'Visual Studio (sln)' runner to check that the sln file has every reference and third party product set up correctly (this should eliminate the 'it works on my machine' issues); and the second is a 'MSBuild' runner that replicates the csproj build process. With the second build step with the right permissions (if your ports are open on the machine you're deploying to, or you're deploying to the same machine as you are on) you could test this in Visual Studio or DOS.
These two build steps should be able to deploy to the IIS website on a staging server; and if the right ports are open on your live or UAT server you could then add a third build step and deploy it onwards (if the first two build steps run properly).
Allow me to start by saying that this is a new and first time TFS deployment with 0 experience in Visual Studio as an added bonus. I've managed to get everything installed and am excited to say that I can even deploy as part of the build process to our different staging environments, but this is where things have gone south.
I'm trying to set up separate build definitions for each stage of development so that I can take advantage of config transforms and use granular permissions for who gets to promote where. In the configuration manager I have it set up so each solution configuration has a 1-1 mapping to a project context and always building 'Any CPU'. The problem is that when I use the /p:Configuration=QA switch in the MSBuild Arguments or just specify it in the 'Items to Build; section of the Build process parameters the build fails with a warning and it doesn't seem to get as far as MSDeploy.
Using the following arguments to MSBuild I am deploying with a default configuration, but again, no love on specifying a configuration.
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=WMSVC /p:MsDeployServiceUrl=10.31.60.109 /p:username=tfsdeploy /p:password=lulz /p:DeployIISAppPath=Bob /p:AllowUntrustedCertificate=True
Here is the warning I get in the TFS Build Explorer when specifying the configuration to use.
C:\Builds\2\Bob\Bob - Final Test\Sources\Bob\Bob.sln.metaproj: The specified solution configuration "QA|Any CPU" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration.
The solution originally was created in VS2008 and a local copy from VSS was pulled down with VS2008 and then pushed into TFS2010 using VS2010 pretty much letting MS work its magic to convert/update.
Any help is greatly appreciated.
The issue I ran into here was that the names of the build configurations were different in the .sln and .csproj files and these can't be mapped to each other as I thought I was doing from within the VS2010 ide.
This is actually a pretty simple error. If you get it, check your spelling in the build definition then verify against the .sln and .csproj files using a text editor like vim/notepad.
Did you get this fixed? I've noticed some of our builds are "AnyCPU" and others are "Any CPU", makes reports a little more interesting!
I've just been upgrading an Azure project to Visual Studio 2010 and have been taking advantage of the new XML configuration transformation feature that is built into VS2010 web projects. It seems to work great with Azure web roles. I even managed to get the Azure project service configuration file to do a similar thing by following the instructions here.
However, I can't seem to get configuration transformation working for the lone worker role in my Azure project. I know that VS2010 only has built-in support for config transformation with web roles, but I found a good article describing how to get config transformations working with non-web projects. I've followed the instructions and it works - but only to a point. It successfully spits out the correct .config file (with appropriate transformations) into the worker role project's own bin directory, but it doesn't pick this new .config file up when it's put into the cloud package.
I suspect there's some MSBuild trickery needed to get this to work, but I don't know MSBuild very well, so am appealing to any gurus out there for help and/or samples :)
I have found the best way to do this is to use msbuild. I usually do this with a separate msbuild file outside my solution so I keep the local dev settings separate from the production settings. You can find out more here. I then can run the build to change the settings and upload the project to Azure. I can also run this to change the settings and then run deploy through VS if I need to debug the problem. I also have a target in the msbuild file that then can revert everything back to local. It would be nice to have these things in VS (which I have asked for from the product team). The sample project is on github.
This is also explained in the book we wrote in the Life Cycle chapter.