We Keep Coding

TargetFramework vs. TargetFrameworks (plural)

In the .csproj file in my .NET Core projects, there are these 3 lines by default:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>
Now if I want to target mulitple frameworks, I can change it to this:
<PropertyGroup>
<TargetFrameworks>netcoreapp2.2;net4.6</TargetFrameworks>
</PropertyGroup>
The difference is subtle, but it's there. When targeting multiple frameworks, you have to use <TargetFrameworks> (plural) instead of just <TargetFramework> (singular).
But why is it made like this? It seems like it would have been easier to just pick one of the two, and then always use that. Which leads me to the thought, that there might be a more complex reason, for choosing to different (although similar) words, depending on whether or not you target more frameworks. Can anyone enlighten me on the topic?

Basically when you want to target a single framework you use <TargetFramework> tag (in the case where you're building an app targeting .net-core), but it's possible also that you may conditionally reference assemblies multiple frameworks by using <TargetFrameworks> (in case you're building an app for both .net standard and .net-core) and then you can conditionally compile against those assemblies by using preprocessor symbols with if-then-else logic
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard1.4;net40;net45</TargetFrameworks>
</PropertyGroup>
<!-- Conditionally obtain references for the .NET Framework 4.0 target -->
<ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
<Reference Include="System.Net" />
</ItemGroup>
<!-- Conditionally obtain references for the .NET Framework 4.5 target -->
<ItemGroup Condition=" '$(TargetFramework)' == 'net45' ">
<Reference Include="System.Net.Http" />
<Reference Include="System.Threading.Tasks" />
</ItemGroup>
</Project>
Source : https://learn.microsoft.com/fr-fr/dotnet/standard/frameworks

You can use TargetFrameworks configuration when you are building a class library that will runs well in .Net Full Framework and .Net Core Framework. This is the best use case to this configuration
It doesn't make sense use multiple target framework if you are building a website or webapi. In this case, use just one target framework.

.NET: Different target frameworks via project configuration

I would like to have two different .net framework targets via configuration in Visual Studio 2015. While for references, you can edit the CSPROJ file and add a conditions, this does not seem to work for the TargetFrameworkVersion in the first PropertyGroup of the file. I have the impression that any Condition in that element causes VS to completely ignore this element and to fall back to the default value of "v4.0".
Is there any way I can get different target framework versions for different configurations?
This is what I tried in the CSPROJ file:
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
...
<!-- this is what VS2015 would put into the file:
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
-->
<!-- this is what does not work: -->
<TargetFrameworkVersion Condition="'$(Configuration)' == 'OLD_Debug' OR '$(Configuration)' == 'OLD_Release'">v3.5</TargetFrameworkVersion>
<TargetFrameworkVersion Condition="'$(Configuration)' == 'NEW_Debug' OR '$(Configuration)' == 'NEW_Release'">v4.0</TargetFrameworkVersion>
...
</PropertyGroup>
...
</Project>
A similar approach with conditions for the assembly references works fine.
EDIT
I found a similar Stackoverflow question:
Targetting multiple .net framework versions by using different project configurations and tried the approach suggested in the non-accepted answer to remove the TargetFrameworkVersion from the first PropertyGroup block, and edit the later <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'OLD_Debug|AnyCPU' "> blocks to contain it, but my assembly is still compiled for framework 3.5 no matter which configuration I use. At least if I look at the assembly from Powershell using [System.Reflection.Assembly]::LoadFrom("C:\PATH\MyAssembly.dll").ImageRuntimeVersion, I always get version 2, not 4.

The approach found in this answer to a similar question works:
Keep the first PropertyGroup without configuration specific settings, remove the TargetFrameworkVersion element from it. And add the TargetFrameworkVersion settings to the configuration specific PropertyGroups which are in the file anyway, just double them for debug/release:
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
...
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'OLD_Debug|AnyCPU' ">
...
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'OLD_Release|AnyCPU' ">
...
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'NEW_Debug|AnyCPU' ">
...
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'NEW_Release|AnyCPU' ">
...
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
</PropertyGroup>
...
</Project>
I verified this as follows:
My assembly references version 2.0.0.0 of the mscorlib assembly for the 3.5 framework (OLD_... configurations), and version 4.0.0.0 of mscorlib for the 4.0 framework (NEW_... configurations).
Using ILSpy, I found that the 3.5 version of my assembly has no attribute for the target framework, as this was only introduced since version 4, but the version 4 framework appears as an attribute of the assembly:
[assembly: TargetFramework(".NETFramework,Version=v4.0", FrameworkDisplayName = ".NET Framework 4")]

C# how to install Windows.Media.Transcoding

In my current project I need to use the Windows Media Transcoding API. However, I can't manage to install it.
Here you can see I'm using the correct namespace.
using System.Windows.Media.Transcoding;
I looked around on NuGet, but couldn't find it there. I read the Microsoft page about it, but that only told me the namespace. I also couldn't find it's Assembly. Could someone please help me install it.

You can follow these instructions:
Modify the target platform by opening your .csproj file with an external editor and add the line
<TargetPlatformVersion>8.0</TargetPlatformVersion>
as for this example
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProjectGuid>{6D41F51D-5A85-4826-9868-14FB3591F280}</ProjectGuid>
<OutputType>WinExe</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>WindowsFormsApplication1</RootNamespace>
<AssemblyName>UseWindowsMediaTranscodingAPI</AssemblyName>
<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<TargetPlatformVersion>8.0</TargetPlatformVersion>
</PropertyGroup>
Reload the solution and add a reference to Windows Core Media DLL
This should already compile.
Additionally to be able handle events and async methods mapping you should add the reference to the system dll:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETCore\v4.5\System.Runtime.InteropServices.WindowsRuntime
Remember that the application will work only on Windows 10.
Source: https://blogs.msdn.microsoft.com/cdndevs/2013/10/02/using-windows-8-winrt-apis-in-net-desktop-applications/

handwritten msbuild ignores rootnamespace for c# dll

I am working on an automated c# build that requires me to write/generate the csproj file and then compile it using the command line. For some reason while the dll is created without issue, the class it contains is dumped into the global namespace instead of the one I have specified in . Does anyone have any idea what might be going on here?
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<OutputType>Library</OutputType>
<RootNamespace>SimpleDependency.Test</RootNamespace>
<AssemblyName>simpledependency.test</AssemblyName>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
</PropertyGroup>
<ItemGroup>
<Compile Include="*.cs" />
</ItemGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>Bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>
I have msbuild set to .net 4.0, and am running this command on the command line:
msbuild /property:Configuration=Release /property:Platform=AnyCPU
I know that it generates the dll successfully because I then have another dependent project that uses the class I have defined in this project, but if I include:
using SimpleDependency.Test;
in that code, I get compile errors saying it cannot find namespace 'SimpleDependency'. Without this using statement, it compiles fine and works. Anyone have any thoughts?

Run MSBuild using the /preprocess:flattened.proj flag. Then load up the resulting file in an XML editor. My recent experience is that when properties are not being seen, it's overwritten someplace later (e.g. setting rather than appending to it) or something about conditions. That's a good start. You might also try getting MSBuildExplorer3 and see if that turns up anything. I'm not familiar with C# projects, but I think you should find where $(RootNamespace) is actually used for its effect, and trace backwards: is it ignored due to a condition, not getting the target variation you expected, etc. Once you know the lay of the land, run MSBuild with /verbosity:diag and grep through that for the target where it's (supposed to be) used, and see what it was thinking.

Copying the feedback from Pierre-Luc into an answer: The rootnamespace appears to only be a suggestion to the IDE to inject whenever creating classes. If the .cs files do not have a namespace specified, rootnamespace will not become the namespace for those classes. More information about that problem in this question.

want different icons with different builds in C#

We have a product but we are doing some rebranding so we need to be able to build and maintain two versions. I used resource files combined with some #if stuff to solve the strings, images, and whatever else, but the program icon is giving me trouble. I couldn't figure it out from msdn or a google search. Thanks!

Are you referring to the application icon? You can edit your project file manually and put in code similar to the following:
<PropertyGroup>
<ApplicationIcon Condition=" '$(Configuration)' == 'Version1' ">Icon1.ico</ApplicationIcon>
<ApplicationIcon Condition=" '$(Configuration)' == 'Version2' ">Icon2.ico</ApplicationIcon>
</PropertyGroup>
<ItemGroup Condition=" '$(Configuration)' == 'Version1' ">
<Content Include="Icon1.ico" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)' == 'Version2' ">
<Content Include="Icon2.ico" />
</ItemGroup>

Create icon files named after your config. (E.g. DebugOld.app.ico DebugBranded.app.ico, ReleaseBranded.app.ico)
Create a pre-build step:
copy "$(ProjectDir)$(ConfigurationName).app.ico" "$(ProjectDir)app.ico"

Set the icon in normal code, and you should be able to use the same techniques as you have elsewhere. You'll need both icons in the resources file (at least so I suspect) but it should work.
Alternatively, set a prebuild step to copy the appropriate icon into a common filename - e.g. copying debug.ico or release.ico into app.ico. A bit hacky, but I think it would work. That way you only end up with one icon in the finished binaries.
Yet another option: look into the build file and see how the icon is built in, then conditionalise it. Marc Gravell did this for references in MiscUtil - the project can be built targeting either .NET 2.0 or 3.5, depending on configuration. I suspect that resources could be conditionalised in a very similar way.