In my TFS build system, I see many MSBuild properties, such as:
$(BinDirectory)
$(ThisDropDirectory)
...
These are not the MSBuild Reserved and Well-Known Properties. How can I find their definitions?
Run with diag[nostic] verbosity, it'll dump all of them at the begging of the log during evaluation, albeit not the file logger for some reason, just the console one, not sure what TFS one would do.
msbuild Foo.csproj /v:diag /t:NonExistingTargetSoItTerminatesAndKeepLogLessNoisy
Related
My C# projectA published via ClickOnce depends on projectB. I need the projectB.dll.config file for projectA to work. While MSBuild copies over projectB.dll.config to projectA/bin/ConfigXY correctly, it is not published. VisualStudio (2017) doesn't even show the file in Application->Publish->Application Files.
As a workaround, I added this to A.csproj:
<Content Include="..\projectB\bin\Release\projectB.dll.config">
<Link>projectB.dll.config</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
Now VS shows the file in the "Application Files" list, but this of course works only for the Release build config. Since I have lots of configs in project A that map to different configs in B, I cannot simple use $(Configuration) in the path.
I have found some suggestions to include ..\**\*.dll.config, but that seems dangerous, as when both the Debug and Release folder exist (from a previous build), I might end up with the wrong one.
What's the right way to do this?
I’d like to post this as a comment, but due to the limitations, I post it as an answer and I am sorry for that.
I did some tests, and it seems, to include the project.dll.config file to be published(shown in Application > Publish > Application Files), we need to include this file to the projectA.
I guess you mean you want to use “..\XXX\XXX\Release\projectB.dll.config” path for Release build and use ““..\XXX\XXX\Debug\projectB.dll.config” path for Debug build without using $(Configuration) right?
Generally, MSBuild uses $(configuration) to switch the configuration mode, if it is not available for you, to my knowledge, from MSBuild side, it is hard or not possible to switch/match the configuration mode.
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'd like to invoke MSBuild to build a single project inside a solution.
Therefore I use
MSBuild MySolution.sln /t:MyProject
Since I have some sophisticated deployment process and I want to save time, I need to build just the one project, but nothing else. Like mentioned here I tried
MSBuild MySolution.sln /t:MyProject /p:BuildProjectReferences=false
which works for project-to-project references, but not for project references defined by the solution (via ProjectSection(ProjectDependencies) in sln-file).
Does anyone know a way to ignore the solution project references also?
I just downloaded TeamCity 7 today and decided to get it up and running for my Azure solution. I am not trying to do anything fancy (yet) and started with a very basic command line build:
msbuild /t:Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
This builds successfully and produces a package that looks like this*:
I then attempted to configure TeamCity in an identical fashion:
This builds successfully and produces a package that looks like this*:
What I don't understand is why there is such a huge discrepancy in the size of the MVC project. Publishing directly from Visual Studio produces the exact same result as my MSBuild command so I'm convinced that TeamCity is the odd man out. Since I assume TeamCity is not broken, can someone please educate me on how to properly configure it so that I get the expected output?
*I have renamed the package files with .zip so that the details were viewable for this post.
Ming's answer helped me solve the mystery. After inspecting the contents of the zip files, I discovered the difference was that my MSBuild package contained bin and obj folders and the TeamCity package did not.
After making this discovery, I realized that I could specify multiple targets to MSBuild and prepended "Clean" to my targets switch like so:
msbuild /t:Clean;Publish /p:Configuration=Release;TargetProfile=Production;PublishDir=S:\HoursTracker\Deployments
As expected, this removed those folders. So apparently, TeamCity specifies "Clean" implicitly for you. Mystery solved.
Windows Azure packages may be larger than we expect. You can rename the cssx file to zip and you will find out what’s inside the package. In addition to the web application’s usual files, there’re a bunch of Windows Azure files. For example, if you enable diagnostics, you will see a diagnostics folder, where you’ll find files used by Windows Azure diagnostics runtime.
Best Regards,
Ming Xu.
Why you specified x64 for msbuild runner? Try selecting tools version as well. You have not specified /p:Platform parameter. Does publish task involve rebuild?
TeamCity starts msbuild with number of /p: parameters taken from " properties and environment variables " section, plus some well-known parameters like configuration name or project name.
I have had my first successful build using CC.Net + MSBuild on legacy project. Only took 8 hours.
My newb question is: Where is the output?
My ArtifactDirectory is empty. Where did everything go?
Did you specify the ThoughtWorks.CruiseControl.MSBuild.dll logger in the msbuild-task? Did you have the xmllogger publisher?
EDIT:
What are you looking for : the results/logs that goes into the dashboard and mail or the website/dll/program you built?
Could you post your project configuration?
EDIT2:
The website/dll you built are located in the outDir you specified in your msbuild task. If you didn't override either the OutDir or the OutputPath property (in your msbuild task or msbuild build script) your website should be located in the WebProject\bin\Release (or Debug)_PublishedWebsites and your dlls should be located in every Project_dir\bin\Release (or Debug).
If you want a common output you need to specify it by overriding OutputPath or BaseOutputPath (see here http://msdn.microsoft.com/en-us/library/bb629394.aspx ).
If your source projects don't compile to custom folders, the code will be located wherever the source was pulled down to on the build box. As Benjamin stated, this will be the workingDirectory specified in the msbuild task.
If you didn't specify a working directory, I believe CruiseControl.net puts code in:
C:\Program Files\CruiseControl.NET\server\[Project Name]\WorkingDirectory