MSBUILD Generate xml documentation file for all projects in solution (without touching the projects) - msbuild

I'm trying to create the XML documentation for all the projects in the solution even when the option its not checked in the project properties (and this is the key point).
I'm using TFS 2010 SP1 and tried with this "/p:TreatWarningsAsErrors=true /p:GenerateDocumentation=true" in the "MSBuild Arguments" field of my build definition. It doesn't generate anything.
I also tried with /p:DocumentationFile=foo.xml, which it does work but I assuming the file gets overridden by the last compiled project, so I tried using a variable instead but with no luck, I tried with
/p:DocumentationFile=$(Project).xml,
/p:DocumentationFile=$(localProject).xml
/p:DocumentationFile=$(localBuildProjectItem).xml
Is there a way to create the XML documentation for all the projects from within MSBUILD even though the option is not checked in the project?
PS: And yes I already see another thread similar to this but I don't want to modify the projects, that's the whole point of doing it with MSBUILD.
Thanks for your time

I also wanted to achieve this and finally I came up with a solution following these steps:
Create a Directory.Build.props file in the solution root folder.
Set GenerateDocumentationFile property to true.
Set DocumentationFile property.
By default you would use $(OutputPath) and $(AssemblyName) properties to set the documentation file name, like this:
<DocumentationFile>$(OutputPath)$(AssemblyName).xml</DocumentationFile>
But unfortunately this does not work as Directory.Build.props file is processed first hence properties set in .csproj files are unavailable at this point.
Fortunately there is another property that gets the current project name: $(MSBuildProjectName)
The output path by default is the following:
for Web projects: bin\
for other projects: bin\$(Configuration)\, e.g. bin\Debug\
To decide whether a project is a web project or not I used the name of the project which ends either with .Web or .WebApi
So the complete Directory.Build.props file looks like this in my case:
<Project>
<PropertyGroup>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
<!-- The rest is omitted for clarity. -->
</PropertyGroup>
<PropertyGroup>
<!-- warning CS1591: Missing XML comment for publicly visible type or member -->
<NoWarn>1591</NoWarn>
</PropertyGroup>
<PropertyGroup Condition="$(MSBuildProjectName.EndsWith('.Web')) Or $(MSBuildProjectName.EndsWith('.WebApi'))">
<DocumentationFile>bin\$(MSBuildProjectName).xml</DocumentationFile>
</PropertyGroup>
<PropertyGroup Condition="!$(MSBuildProjectName.EndsWith('.Web')) And !$(MSBuildProjectName.EndsWith('.WebApi'))">
<DocumentationFile>bin\$(Configuration)\$(MSBuildProjectName).xml</DocumentationFile>
</PropertyGroup>
</Project>
As you can see there is also a <NoWarn>1591</NoWarn> property set which tells the compiler not to produce warning messages for publicly visible types where XML document is missing.
Hope it helps.

Open your process template (i.e.: $/yourproject/BuildProcessTemplates/DefaultTemplate.xaml)
Scroll down to find the Compile the Project activity.
Add a new variable named DocumentationFile, type=String, scope=Compile the Project
Set its default value to:
String.Format("{0}.XML", System.IO.Path.GetFileNameWithoutExtension(serverBuildProjectItem))
Save changes and scroll down to Run MSBuild for Project activity.
In CommandLineArguments, set the following value:
String.Format("/p:SkipInvalidConfigurations=true {0};DocumentationFile={1}", MSBuildArguments, DocumentationFile)
Check-in the changes and build. This should generate the documentation even if it was not set by the project.

Related

What is the proper way to add a file to XYZ.csproj.FileListAbsolute.txt?

My build code creates one extra file in the bin folder. I want it cleaned when the solution is cleaned. However, the name of the file is determined by the AssemblyName property of the project. So, if this property is changed (rare, but happens), then the only way to have the old file cleaned is if it is written in XYZ.csproj.FileListAbsolute.txt.
Do I just write to XYZ.csproj.FileListAbsolute.txt whenever I create my file or is there a better way to do it?
OK, I found it.
Just add the file to the FileWrites item list, like this:
<ItemGroup>
<FileWrites Include="$(SomeFileYouWantCleanedUpOnClean)"/>
</ItemGroup>
In my code this is part of a target than runs BeforeBuild and BeforeRebuild, but it may as well work when defined in the global scope.
The proper way to clean up a file is to write your own build target in the *.csproj file. Like this:
<Target Name="MyClean" AfterTargets="Clean">
<ItemGroup>
<ToBeCleaned Include="$(SomeFileYouWantCleanedUpOnClean)"/>
</ItemGroup>
<Delete Files="#(ToBeCleaned)" />
</Target>
You should never ever had to modify (nor care about) the FileListAbsolute.txt file.

Xamarin forms: converted PCL to .net standard libraries and now I can't add new XAML pages

I recenty went through the process of converting all PCL's in my solution to .net standard libraries (not sure if its related nor not, just mentioning it in case).
Now, when I try and add a page, It adds the Xaml and the xaml.cs files into the project without any link or connection, so they wont compile:
Googling suggests I can go in and edit the .csproj to add a dependency between the two, but this is a horrible solution long term.
Any way to fix this "properly"?
I've tried dragging and dropping existing files in from windows explorer into VS2017, adding new through the add new dialog, adding existing through add existing and it all exhibits the same behaviour.
Thanks
OK, to answer my own question. Seems like you need to put in a workaround for the time being:
https://forums.xamarin.com/discussion/comment/288205/#Comment_288205
In the .csproj:
<ItemGroup>
<!-- https://bugzilla.xamarin.com/show_bug.cgi?id=55591 -->
<None Remove = "**\*.xaml" />
< Compile Update="**\*.xaml.cs" DependentUpon="%(Filename)" />
<EmbeddedResource Include = "**\*.xaml" SubType="Designer" Generator="MSBuild:UpdateDesignTimeXaml" />
</ItemGroup>
And remove all existing XAML Pages referenced in the .csproj file such as EmbeddedResources and Compile directives

Exporting code style settings from IntelliJ IDEA version 14.1.5

I'm using the updated version of the IntelliJ IDEA and am trying to export my code style settings so that they can be used by all developers working on a particular project. I read the tutorials at https://confluence.jetbrains.com/display/IntelliJIDEA/Code+Styles and http://forum.shakacode.com/t/sharing-your-intellij-rubymine-webstorm-codestyle-among-developers/240, which seems fairly simple.
Unfortunately that is not how my 'export settings' pane looks like, and I don't have a line that says 'code styles'. Mine looks like
The closest I can find is the line I highlighted which has CodeStyleSettingsManager in it along with a whole bunch of other stuff. However I tried using that and extracted the .jar file only to find that there was nothing much inside at all.
Does anyone know a way of exporting code styles that works with the latest version of IntelliJ?
Edit: My codeStyleSettings.xml file only contains the following:
<project version="4">
<component name="ProjectCodeStyleSettingsManager">
<option name="PER_PROJECT_SETTINGS">
<value/>
</option>
<option name="USE_PER_PROJECT_SETTINGS" value="true"/>
</component>
</project>
I don't understand, why you don't see Code Style in your list (it appears in my IDEA 14.1.5), but...
(...) export my code style settings so that they can be used by all developers working on a particular project
A better way to share the project code style across all developers is to include it in your VCS repository. Pulling such a commit will apply those code styles automatically. This is the file: project/.idea/codeStyleSettings.xml. If your VCS is set to ignore .idea/, add an exception for this file.
If you don't see this file at all, you're probably using a local formatter and your Project scheme is unchanged. In this case, go to Settings > Editor > Code Style > Scheme: Manage, select your formatter and click Copy to Project.
Update
Code style files only state the difference to the IDEA Default Code style (which is always the same). You can try this yourself: create a new project, go the the Code Style settings, select Project and change only one option. The codeStyleSettings.xml file will be created, and it will contain only this one option. If you could export your code style settings, the output would be exactly the same.

Nested variables in Wix

I am creating a WIX template for my projects to ensure a relatively standard layout.
I have defined a variable to reference the Main Application using <?define MainApp="MyApp"?> where MyApp is the name of the referenced project. I then use the MainApp variable to reference the project's properties in the .wxs and .wxi files.
However, I have an issue when referencing nested properties.
$var.($(var.MainApp).ProjectName) expands to "MyApp" without issue.
$var.($(var.MainApp).ProjectDir)Resources\Main.ico expands to $var.(MyApp.ProjectDir)Resources\Main.ico
$var.($(var.MainApp).TargetPath) expands to $var.(ConsoleApplication1.TargetPath)
etc...
My aim is to create a single definition for my main application, thus eliminating a search/replace, which I find clunky.
As you've found, nested preprocessor variables are not supported by the WiX toolset today.

Adding a Compiler PreprocessorDefinitions in VS2010 C++ based on the value of %(Link->SubSystem)

I would have expected the following snippet of msbuild to work at the bottom of my .vcxproj files:
<ItemDefinitionGroup>
<ClCompile>
<PreprocessorDefinitions Condition='%(Link.SubSystem)'=='Windows'>SomethingWinSpecific;%(PreprocessorDefinitions)
</ClCompile>
</ItemDefinitionGroup>
except no matter what I do %(Link.SubSystem) is empty. I even printed out its value in various targets throughout a build and it appears to remain empty until the Link step begins. So my question is, is there any way to access the value of Link.SubSystem before the Compile step?
Link.SubSystem distinquishes between a Windows app and Console App, so Platform will not work.