I am trying to set up a Build on an on premise Team Foundation Server 2015 using web.config transformations. The transformations work fine based on the build configuration I select. I have 3 build configurations: Debug, Release, and one that I created, called "Staging". I am trying to make it so I can re-use the same Build for different environments by setting the $(BuildConfiguration) variable at queue time. In my TFS build's "Visual Studio Build" step, when I set the $(BuildConfiguration) to "debug" the build is output to the agent folder like this: $(Build.SourcesDirectory)\projectFolder\obj\Debug\Package\PackageTmp. If I set it to "release", then it goes to $(Build.SourcesDirectory)\projectFolder\obj\Release\Package\PackageTmp. In both cases the Web.config file is transformed correctly.
However, if I set the build configuration to "Staging", the files are still placed in the "debug" folder $(Build.SourcesDirectory)\projectFolder\obj\Debug\Package\PackageTmp instead of a "Staging" folder. (Transformations also work fine in this case, and use the staging values)
This creates a problem in my "Copy Files" step. I have the "Source Folder" value in that step to $(Build.SourcesDirectory)\projectFolder\obj\ $(BuildConfiguration) \Package\PackageTmp, but when using "Staging", it cannot find the source folder because TFS is placing the build files in the "Debug" folder.
Is there a way to force TFS to place the built items (my web app files, basically) in a folder matching the build configuration parameter, in this case, "Staging"?
A note: It's best to not use web.config transformations, but to build once and allow your web.config to be transformed at deployment time (either by injecting appropriate values or by using MSDeploy parameters).
That said, you can control the output folder with the /p:OutDir= MSBuild argument.
I suspect, however, that you just need to open up your project settings in Visual Studio, go to the Build tab, and set an appropriately-named output folder there.
Related
I have a ClickOnce project that I'm publishing on DevOps. I've set the MSBuild Arguments property for the WinForm solution's build stage in DevOps to /target:Publish in order to trigger the creation of all the ClickOnce files:
However, that solution also contains an SSDT project, and adding the /target:Publish setting appears to then cause the build process to try publish the SSDT too. That then fails with the error:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(1808,5):
error MSB4044: The "SqlPublishTask" task was not given a value for the
required parameter "SqlPublishProfilePath"
Presumably it's failing because there's no publish profile specified in a build parameter for the SSDT to use.
I don't want MSBuild to publish the DacPac to a server, I just want it to create the DacPac. How can I stop the /target:Publish triggering the SSDT publish, is there another build argument I can add to stop that happening?
Notes on what I tried so far to solve this, none of which has worked:
Read about the -target switch in the MS Build official docs in the MSBuild command-line reference and in the MSBuild targets section.
Looked at the code in the .csproj file to try and identify the 'Publish' sections - think Publish must also call Build.
Unticking Deploy for the SSDTs in the solution configuration in VS
Adding entries for False in the Release and Deployment configurations in the SSDT's .csproj file, and also setting that to false for the Debug configuration (as per this question)
Setting MSBuild to only publish one project using the MS Build arguments on DevOps (as per this answer)
Considered pulling the ClickOnce publish out into an entirely separate stage using Mage.exe as per this Walkthrough: Manually deploy a ClickOnce application
Tried to create a publish profile that doesn't actually publish, so that the publish stage can complete (was looking at this question for ideas on that and also the official documentation for SqlPackage.exe)
Eventually I solved the issue above a completely different way. Instead of getting MSBuild to do what I wanted it to, I instead split the solution configuration in two, with one stage for the databases and one for the WinForms project without the databases.
I then used two separate VS Build stages on DevOps with only the WinForms stage still having /target:Publish set.
I've written that up here, but would still like to know the answer to whether it's possible to tell MSBuild not to build the SSDTs when the target is set to Publish?
I'm attempting to create a build that will build my solution, apply web.config transforms as necessary and finally copy desired output (a built web api project) to the artifacts area of the build.
I'm using the Deployment...Azure WebApp Template with the Azure App Service Deploy step disabled (as we're in the middle of a move to Azure), with the following build arguments in the build step:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\" /p:AutoParameterizationWebConfigConnectionStrings=False
All works as expected, apart from the structure of the resulting zip file, which has the following structure:
{ZipFileName}{ProjectName\Content\C_C\a\1\s\Api{ProjectName\obj\Release\Package\PackageTmp...{BuildContent}
I'd like the content to be at the root of the published zip file if possible. Is the best way to manipulate the content of $(build.artifactstagingdirectory) using Powershell or a number of the other built in build tasks?
You don’t need to worry about it, because it won’t keep the folder structure (Just the files and folders in PackageTmp folder) after deploy to web server (e.g. IIS, Azure Web App)
If you still need to just include the files in PackageTmp folder, you can add build step to archive file to zip file through Archive Files step.
For Visual Studio Build step, specify /p:DeployOnBuild=true to MSBuild Arguments.
I am brand new to using TeamCity.
I have my .NET C# application building via a MSBuild "build step" in TeamCity. Once it is built, I would like TeamCity to copy the entire contents of the "Release" folder to a secondary location where we keep current and recent builds.
I cannot build to this location directly because there are other files which my application requires (databases, XML config files, etc..) that reside permanently in the Debug and Release folders. I know this is horrible and I would need a soapbox to complain about the decisions my predecessor made, but for not I am forced to keep that portion as-is.
You can add a command line build step with a simple xcopy command.
It will be executed only when every previous build step succeeds.
I am newbie to TFS.
I am trying to automate process of build upon checking in the code in TFS.
I setup a Controller and an Agent. I created a new build definition and set a "build" and "drop" folder on c:.
I check in the code, expecting to see the generated dll files in "drop" folders. There's none, just "logs" folder. The "binaries" folder in "build" folder is also empty. Apparently the binaries are not being generated at all. How can I have MSBuild to generate the dll files?
They are generated when I compile the website locally on my development machine under "bin\" folder. The solution is comprised of two separate projects: "core" and "web" where "core" is referenced within "web".
Any thoughts?
What is the Summary showing of your build that ran? Or are there errors in your build? You can check the log of the build by opening the build in Visual Studio and then click View Log.
I've got a fairly large MVC2 project in TFS which gets built automatically on checkin (Continuous Integration)
At present, the fully built version is dumped on a network share on our dev IIS server. \\Server\wwwrootLatest
TFS of course creates lots of sub-folders since it's just doing a build, it isn't even aware that it's drop directory is a wwwroot.
This means that to actually USE the build, we need to go and manually create an IIS App which points at the appropriate directory - which defeats the whole object of the exercise.
When we do a manual publish to that server, we use "File System" as the method and just overwrite the files in the UNC share \\Server\wwwroot
(When publishing to other environments, we use full-on MSDeploy.)
What I'd like to do is convince TFS to do a "File system" publish after the build completes and duplicate what we do on a manual publish eg:
Drop directory is \\Server\Build which would result in something like \\Server\Build\Project\Date.Rev\
After that is complete, we want it to publish to \\Server\wwwrootLatest - we can then set up the App once which will always contain the latest version but will still have a full history if required.
The only examples I've been able to find use MSBuild commands in the build definition (fine) but all use MSDeploy to do a full-on publish. I'm not sure how to automate what I want to do
Any help appreciated.
In your drop folder a folder named _PublishedWebsites is generated automatically. It contains files you need to put in wwwroot. You can use CopyDirectory build activity to copy them automatically.