We Keep Coding

How can I add information to an endpoint in NSwag for .NET Framework?

Pretty much the same as this question, but for .NET Framework/Webforms instead of .NET Core:
How can I add a little information to a controller endpoint, so that it is displayed in the swagger UI in .NET Framework?
Just adding doc comments does not work, and the next step in the linked answer, adding
<PropertyGroup>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
<NoWarn>$(NoWarn);1591</NoWarn>
</PropertyGroup>
in the .csproj also doesn't work - there's no XML fie generated (but I suspect that it's a .NET Core setting anyway).
I found the doc comment documentation saying that you can create the XML file by using csc XMLsample.cs /doc:XMLsample.xml. HOWEVER, csc is called "automatically" in the C# build target, and not in my .csproj file. If there is a way to pass the /doc parameter to it, that would be a solution, but it feels like that might be the wrong way to go about it.

I worked on this for a whole day yesterday, but literally 10 seconds after I posted this answer I found the setting
ProjectSettings => Build => Output => XML documentation file
I turned that on and now it works.

(C#) Error with building multiple target frameworks: "Cannot open 'MyApi.dll' for writing"

I am following this guide to automatically generate an API client with NSwag. But this client needs to support multiple target frameworks:
<TargetFrameworks>netcoreapp2.2;net452;net462;net472;net48</TargetFrameworks>
When I try to build this client, I get multiple errors like this:
(CS2012) Cannot open 'MyApi.dll' for writing -- 'The process cannot access the file 'MyApi.dll' because it is being used by another process.'
I suspect this is because each framework is building asynchronously and the DLL produced from my API is trying to be read by each process. How can I fix this issue / make each target framework build synchronously?

Well, I found a solution. My lack of understanding around the guide I was reading and the build process meant I wasn't asking the right questions.
I had this build target specified in my .csproj (as directed in the guide):
<Target Name="NSwag" BeforeTargets="PrepareForBuild" Condition="'$(GenerateCode)'=='True' ">
<Exec Command="$(NSwagExe_Core22) run nswag.json /variables:Configuration=$(Configuration)" />
</Target>
This target was running for each target framework I had specified in my <TargetFrameworks> tag. This was the task that was running in parallel to itself and causing the error from my question.
After a LOT more googling, I found this question and (consequently this answer) which gave me the solution I needed:
On multi target frameworks I use BeforeTargets="DispatchToInnerBuilds" so my custom command is only exeuted once before every build
So my final build target was as simple as this:
<Target Name="NSwag" BeforeTargets="DispatchToInnerBuilds" Condition="'$(GenerateCode)'=='True' ">
<Exec Command="$(NSwagExe_Core22) run nswag.json /variables:Configuration=$(Configuration)" />
</Target>
It should also be noted that this solution might not work for all people looking for their build targets to run once per build. See this issue comment that provides a similar answer but with more detail about multi-project solutions.

How to read a MSBuild property in a given project in runtime?

I want to access a MSBuild variable inside an unit test, which is a .NET 4.5 class library project (classic csproj), but I failed to find any articles discussing a way to pass values from MSBuild into the execution context.
I thought about setting an environment variable during compilation and then reading that environment variable during execution, but that seems to require a custom task to set the environment variable value and I was a bit worried about the scope of the variable (ideally, I only wanted it to be available to the currently executing project, not globally).
Is there a known solution to reading an MSBuild property from inside a DLL project in runtime? Can MSBuild properties be "passed as parameters" during execution somehow?

I finally made it work by using the same code generation task that is used by default in .Net Core projects. The only difference is that I had to manually add the Target in the csproj file for it to work, as code creation is not standard for framework projects:
<Target Name="BeforeBuild">
<ItemGroup>
<AssemblyAttributes Include="MyProject.SolutionFileAttribute">
<_Parameter1>$(SolutionPath)</_Parameter1>
</AssemblyAttributes>
</ItemGroup>
<WriteCodeFragment AssemblyAttributes="#(AssemblyAttributes)" Language="C#" OutputDirectory="$(IntermediateOutputPath)" OutputFile="SolutionInfo.cs">
<Output TaskParameter="OutputFile" ItemName="Compile" />
<Output TaskParameter="OutputFile" ItemName="FileWrites" />
</WriteCodeFragment>
</Target>
The lines with Compile and FileWrites are there for it to play nicely with clean and such (see linked answers in my comments above). Everything else should be intuitive enough.
When the project compiles, a custom attribute is added to the assembly, that I can then retrieve using normal reflection:
Assembly
.GetExecutingAssembly()
.GetCustomAttribute<SolutionFileAttribute>()
.SolutionFile
This works really well and allows me to avoid any hardcoded searches for the solution file.

I think you have a couple of options:
Use environment variables, like you already suggested. A custom task maybe required to do that, but it is easy to do, without any extra assemblies on your part. The required global visibility might be an issue tough; consider parallel builds on a CI machine, for example.
Write a code fragment during build and include that into your resulting assembly (something akin to what you have already found under the link you suggested in your comments.
Write a file (even app.config) during build that contains settings reflecting the MSBuild properties you need to have; read those during test runs.
(BTW, what makes little sense, is to attempt to read the MSBuild project file again during runtime (using the Microsoft.Build framework). For once that is a whole lot of work to begin with, for little gain IMHO.
And even more important, you most likely - depending on the complexity and dependencies of your properties - need to make sure you invoke the MSBuild libraries with the same properties that where present during the actual build. Arguably, that might put you back were you started from.)
The last two options are best suited because they share equal traits: they are scoped only to the build/test run you currently have (i.e. you could have parallel running builds without interference).
I might go for the third, because that seems to be the easiest to realize.
In fact I have done so on a larger project I've been working on. Basically, we had different environments (database connection strings, etc.) and would select those
as a post build step by basically copying the specific myenv.config to default.config.
The tests would only ever look for a file named default.config and pick up whatever settings are set in there.

Another version, compiled from several internet sources, get environment variable when building, then use its value in code
file AssemblyAttribute.cs
namespace MyApp
{
[AttributeUsage(AttributeTargets.Assembly)]
public class MyCustomAttribute : Attribute
{
public string Value { get; set; }
public MyCustomAttribute(string value)
{
Value = value;
}
}
}
file MainForm.cs
var myvalue = Assembly.GetExecutingAssembly().GetCustomAttribute<MyCustomAttribute>().Value;
file MyApp.csproj, at the end (get %USERNAME% environment variable in build, generate SolutionInfo.cs file, automatically include it to build)
<Target Name="BeforeBuild">
<ItemGroup>
<AssemblyAttributes Include="MyApp.MyCustomAttribute">
<_Parameter1>$(USERNAME)</_Parameter1>
</AssemblyAttributes>
</ItemGroup>
<WriteCodeFragment AssemblyAttributes="#(AssemblyAttributes)" Language="C#" OutputFile="SolutionInfo.cs">
<Output TaskParameter="OutputFile" ItemName="Compile" />
<Output TaskParameter="OutputFile" ItemName="FileWrites" />
</WriteCodeFragment>
</Target>

How would I call a constructor defined in C# from MSBuild?

I'm trying to convert this C# code to run in MSBuild:
var uri = new Uri(s1);
var result = uri.MakeRelativeUri(new Uri(s2)).ToString();
I'm not quite sure how you would call the Uri constructor from MSBuild, though. Here is what I have so far:
<PropertyGroup>
<!-- <FirstUri>???</FirstUri>
<SecondUri>???</SecondUri> -->
<RelativeUri>$(FirstUri.MakeRelativeUri($(SecondUri)))</RelativeUri>
<AsString>$(RelativeUri.ToString())</RelativeUri>
</PropertyGroup>
As you can see, I've commented out the FirstUri and SecondUri snippets because I couldn't figure out how to get them to work. I've tried new Uri($(FirstString)), but that just caused it to be subsituted with the literal value of s1 (e.g. "new Uri(C:\Users)").
How do I get this to work? Any help would be appreciated, thanks!
edit: Well, it looks like it's not possible from straight MSBuild. I've accepted Mark Arnott's answer of creating a custom MSBuild task, although I don't think I'll be doing this by myself.
Perhaps if you were running on Windows-only clients, you could do something like this:
<Exec Command="powershell '(New-Object [System.Uri] ...'" />
I'm a bit hesitant to start a whole new process just to create relative paths though, so that's a bit of a dealbreaker.

I am not sure what your goal is, but if you really need MSBuild to run some C# code, you need to use inline tasks.
See MSDN's Walkthrough: Creating an Inline Task
Most of the time MSBuild runs pre-compiled tasks and command line utilities.

Normally you would do this:
<PropertyGroup>
<FirstUri>$([System.Uri]::new($(FirstString)))</FirstUri>
<SecondUri>$([System.Uri]::new($(SecondString)))</SecondUri>
<RelativeUri>$(FirstUri.MakeRelativeUri($(SecondUri)))</RelativeUri>
<AsString>$(RelativeUri.ToString())</AsString>
</PropertyGroup>
However, System.Uri is not an available type in MSBuild. The MSBuild Property Reference contains a list of types available, but I found it is not inclusive of everything. I have found the other types like System.Version and constructors (not just static functions) available.

MSBuild handling circular dependencies

I am new to MSBuild. Just started trying it two days ago, and now I am just testing it. I have run into a problem where I get this error:
"c:\Users\martinslot\Documents\Visual Studio 2010\Projects\MultifileAssembly\SpecializedBuild.xml" (BuildNumberUtil target) (1) ->
c:\Users\martinslot\Documents\Visual Studio 2010\Projects\MultifileAssembly\SpecializedBuild.xml(4,34): error MSB4006: There is a circular dependency in t
he target dependency graph involving target "BuildNumberUtil".
My MSBuild script look like this:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="BuildNumberUtil" DependsOnTargets="BuildStringUtil" >
<Message Text="=============Building modules for NumberUtil============="/>
<Csc TargetType="Module" Sources="NumberUtil/DoubleUtil.cs; NumberUtil/IntegerUtil.cs" AddModules="/StringUtil/StringUtil"/>
<Copy SourceFiles="#(NetModules)" DestinationFolder="../Output/Specialized"/>
</Target>
<Target Name="BuildStringUtil" DependsOnTargets="BuildNumberUtil" >
<Message Text="=============Building modules for StringUtil============="/>
<Csc TargetType="Module" Sources="StringUtil/StringUtil.cs;" AddModules="/NumberUtil/IntegerUtil;/NumberUtil/DoubleUtil"/>
<Copy SourceFiles="#(NetModules)" DestinationFolder="/Output/Specialized"/>
</Target>
</Project>
I understand the problem, actually I created this small example to see if MSBuild understood and could somehow correct the problem. How do I solve this?
My problem is that the two targets compile modules that rely on eachother. Does someone here have a solution on how to handle this kind of problem with MSBuild? Maybe I am constructing this in the wrong way?

You simply cannot build projects with circular dependencies. How could you? Which do you build first? There may be some esoteric, convoluted, incorrect way of doing so, but why do it? Circular dependencies usually indicate a design flaw. Fix the design, and you no longer have a circular dependency issue.

It is possible to construct Circular Modules within the scope of MSBuild and Visual Studio; however, doing so has a very limited set of situations where it would be valid to do so.
One key way to do this, if you're planning on using Xaml within your code, is to remove the Sources aspect of the Csc tag and generate your own .response file which actually points to the code you wish to inject. Within the Csc tag attributes you'd specify this file yourself in the ResponseFiles attribute.
Within your .response file, you would then break your application down into its assembly and netmodule components, making sure to include the core assembly's files first at all times. Typically the Csc tag's attributes are directly translated into Csc.exe command line parameters. The parameter names do not always match up. For the sake of resolution it's best to use full, non-relative, paths when referring to files (example, partial, .response below):
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\SearchContexts\StringSearchType.cs"
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\UI\Themes\Themes.cs"
/target:module /out:bin\x86\Debug\InternalName.UI.dll
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\UI\EditDatabaseImageControl.xaml.cs"
"X:\Projects\Code\C#\Solution Name\InternalName\ProjectName - InternalName\obj\x86\Debug\UI\EditDatabaseImageControl.g.cs"
You'll notice that this will end up with merging your multiple sets of Targets into one, and that I've included the xaml generated code myself. This is partly why you remove the Sources aspect, as the Xaml Page generator part of the MSBuild task automatically injects information into the #(Compile) set. Since there's a Debug/Release configuration, in the area where you define the response file to use, I create two versions of the response (since I'm using a T4 template):
ResponseFiles="$(CompilerResponseFile);InternalName.$(Configuration).response"
If you intended to include more than one platform in your code you'd likely need C*P response files where C is the number of configurations (Debug|Release) and P is the number of platforms (x86, x64, AnyCpu). This kind of solution would likely only be a sane method by using a generator.
The short version of this: it is possible to create circular modules so long as you can guarantee that you'll compile it all in one step. To ensure that you maintain the build functionality that is afforded to you with the Xaml build step, your best bet is to start with a normal C# project, and create your own .Targets file from the $(MSBuildToolsPath)\Microsoft.CSharp.targets in the <Import ... tag near the bottom. You'll also likely need a secondary csproj for design purposes since a large portion of intellisense is lost by using this workaround (or use a csproj Condition attribute where the target is selected by some flag you set). You'll also notice certain Xaml editors don't seem to like the binding to netmodule namespaces, so if you bind to types in a netmodule you'll likely have to do them in codebehind (I haven't tested workarounds for this since there's usually ways around static namespace binding)
For some reason within all this, the .baml compiled .xaml files are implicitly understood by the Csc compiler, I haven't been able to figure out where it's deriving this from a command argument, or if it's just implicit by design. If I had to guess they're inferred by the g.cs files associated to what you include in your list of included files.

Observe that this is occurred for web application (either ASP.NET standard web application or ASP.NET MVC application) and fix for this problem is to be removed the below line in ".csproj" file.
<PropertyGroup>
<BuildDependsOn>
$(BuildDependsOn);
Package
</BuildDependsOn>
</PropertyGroup>