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!
Related
My Visual Studio 2019 solution contains several projects, some of which I don't want to be built as part of continuous integration. Specifically, I'm trying to exclude tooling and unit tests.
In Visual Studio, I have created a new solution configuration and unchecked the "Build" box for each project I don't want to be built.
In TeamCity, I have specified the name of the new solution configuration to use. However, TeamCity continues to attempt to build all projects within the solution.
[I had included screenshots of my solution configuration, TeamCity build configuration, and resulting TeamCity log but I do not have enough reputation to post images apparently.]
From everything I could find so far, unchecking "Build" from the solution configuration used by TeamCity is supposed to exclude that project from building.
I figured it out by finally noticing that the TeamCity log was showing the build configuration as "ReleaseCI|Mixed Platforms" instead of "ReleaseCI|Any CPU". On other projects, I only needed to specify the configuration. For this project, I apparently have to specify the platform as well.
I have a large solution of dozens of projects. Since yesterday (and for no good reason that I can find) the projects are refusing to build, with Visual Studio's build output window simply stating (eg)
1>------ Skipped Rebuild All: Project: Api.Models.Common ------
There are already a few similar q/a's here about the reasons why VS may decide to skip a build (Configuration not set to build, or set to build wrong target). I'm not interested in guesses as to why this isn't building. I'd really like answers to help me diagnose this, and have Visual Studio tell me why it thinks it can skip the build.
Is there a way to have VS generate anything more detailed than Skipped rebuild for example? It must be calling msbuild under the covers right? So can I have Visual Studio pass additional parameters to msbuild so that it generates diagnostic log output?
(For what it's worth - calling msbuild from the command line builds the projects as expected, so it seems like my issue is something quirky that VS is doing).
I'm using VS 2017 - 15.9.4
If you have any unload projects, you must load it or you remove it in solution.
Note: My unloaded project was the result of a permission issue. VS warned that a project was configured to use IIS. To run the project with IIS required launching VS as an administrator.
This was happening in my solution with Visual Studio 2019. I just migrated my applications from .Net Framework 4.6 to .NET5, almost all the projects were not building, it gets always skipped. The reason was that after the migration the tool upgrade assistant was not setting the Target Framwework as in the preceding image (Right-click on the project and then click on Properties).
After setting it to the right framework, in my case, it was .NET 5.0, the project started to build.
I am currently trying to set up a automated publish using MSBuild and am now realizing that it produces a different output when doing it from MSBuild instead of Visual Studio. I am not sure what I am missing here, but for some reason it is copying different project files into the route web project directory.
Is there a way to simulate a Visual Studio Publish using MSBuild? I am currently doing this with an Orchard Project, figured that would be worth mentioning.
Here is the command I am currently using to do this:
/p:PublishProfile="exampleprofile";DeployOnBuild=true;VisualStudioVersion=12.0;
FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v4.5";
PublishProfileRootFolder=%WORKSPACE%\src\Orchard.Web\Properties\PublishProfiles;
Password=ExamplePass;Configuration=Release
As far as I can understand, you're trying to simulate a ClickOnce publish using a manual msbuild routine. You can achieve that by calling msbuild with the correct parameters. To simulate the ClickOnce, the target publish is available for you.
msbuild MyProj.csproj /t:Publish
Given your specifications, you have to be able to run multiple publish configurations, each one having its own output settings. To be able to run multiple profiles, I would recommend that you abandon the PublishProfile attribute (I never understood how to get it to work) and switch to the BuildEnvironment as showed here :
https://wallism.wordpress.com/2009/12/21/msbuild-and-multiple-environments/
(Focus on the "Setting up the customizations" part)
You have to adapt your call to msbuild to include your build environment
msbuild MyProj.csproj /t:Publish /p:BuildEnvironment=MyConfig
Just for a little test, for you to know if this is useful, follow the tutorial, create your target, and add a
<PropertyGroup>
<PublishUrl> Add a custom path here </PublishUrl>
<InstallUrl> Add the same path here </InstallUrl>
</PropertyGroup>
to your target file.
Run then the msbuild and let me know if you solved your problem
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.
I'm facing quite a problem while setting up automated TFS Builds. Basically I created new configuration called Tests, added transform config, defined different connection strings for the Database. Then defined TFS build, building whole solution with MSBuild arguments /p:DeployOnBuild=True /p:Configuration=Tests.
The problem is that in the drop location (Build_PublishedWebsites\Project) I get web.config, web.debug.config, web.release.config and web.tests.config, however I would expect just one transformed web.config.
I already checked PDC presentation Web Deployment Painkillers: Microsoft Visual Studio 2010 & MS Deploy but didn't help.
Thanks for any answer.
Web.config transforms are part of the new Web Publishing Pipeline (WPP) in Visual Studio 2010.
During the build process the "CopyWebApplication" target is executed to copy the website to the _Websites folder on the build output directory. Due to backwards compatibility reasons, MSBuild uses the "old" (VS2008) copy behavior by default and not the new WPP system.
To opt-in to using WPP, set the following MSBuild properties:
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False