Unable to change AssemblyName dynamically within the CSPROJ file

Question

I'm using Visual Studio 2022 to create a simple C# class library targeting .NET6 and .NET Framework 4.8.... and I've been tearing my hair out on this one all day.

I want to name my assembly differently depending on the framework. Specifically, I want to append ".Core" to my assembly name if it's a .NET build.

But it seems I can't utilize the $(TargetFramework) macro within a .csproj file to change the value of the AssemblyName property.

For example, this works when using the $(Configuration) macro:

<PropertyGroup>
    <TargetFrameworks>net6.0;net48</TargetFrameworks>
           ...
</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <AssemblyName>$(MSBuildProjectName).Debug</AssemblyName>
</PropertyGroup>

But this doesn't:

<PropertyGroup>
    <TargetFrameworks>net6.0;net48</TargetFrameworks>
         ....
</PropertyGroup>

<PropertyGroup Condition="'$(TargetFramework)' == 'net6.0'">
    <AssemblyName>$(MSBuildProjectName).Core</AssemblyName>
</PropertyGroup>

I've been reading similar questions, specifically this one but I'm not sure it applies to CSPROJ files. Moreover the answer doesn't provide an example; it's unclear to me how it could be implemented in a CSPROJ.

Can AssemblyName be overridden by placing a condition on the target framework?

The errors I'm receiving are:

NuGet package restore failed. Please see Error List window for detailed warnings and errors.

Failed to restore D:\src2\csharp\dummy1\dummy1.csproj (in 0.6 ms).
1>C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5): error NETSDK1005: Assets file 'D:\src2\csharp\dummy1\obj\project.assets.json' doesn't have a target for 'net6.0'. Ensure that restore has run and that you have included 'net6.0' in the TargetFrameworks for your project.

1>Done building project "dummy1.csproj" -- FAILED.

1>C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5): error NETSDK1005: Assets file 'D:\src2\csharp\dummy1\obj\project.assets.json' doesn't have a target for 'net48'. Ensure that restore has run and that you have included 'net48' in the TargetFrameworks for your project.

1>Done building project "dummy1.csproj" -- FAILED.

using command line tools "dotnet build" and "msbuild", the project succeeds (thanks @Jimmy!). It's only in Visual Studio that it doesn't work. I'm starting to suspect my problem isn't renaming the assembly name, but something else in Visual Studio that needs to be done.

With @Jimmy pointing me to the build tool, I'm suspecting that this really is a Nuget problem, and NOT an assembly renaming issue, though the error only appears when trying to rename the assembly...

Answer 1

The easiest (and dumbest) way to solve that would be running a few commands to update the .csproject with those values depending on the compilation need. For instance:

given the file project.csproj:

<PropertyGroup>
    <TargetFrameworks>net6.0;net48</TargetFrameworks>
           ...
</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <AssemblyName>$(MSBuildProjectName).Debug</AssemblyName>
</PropertyGroup>

I would run run:

sed -i.backup 's/(Configuration)\x27 == \x27Debug\x27/\(TargetFramework\)\x27 == \x27net6.0\x27/' project.csproj

and then run:

sed -i.backup 's/(MSBuildProjectName).Debug/(MSBuildProjectName).Core/' project.csproj

that would transform the project.csproj on:

<PropertyGroup>
    <TargetFrameworks>net6.0;net48</TargetFrameworks>
           ...
</PropertyGroup>

<PropertyGroup Condition="'$(TargetFramework)' == 'net6.0'">
    <AssemblyName>$(MSBuildProjectName).Core</AssemblyName>
</PropertyGroup>

I know that isn't the coolest thing (transforming files like that in devops time) but that would definitely do the trick.

You could also wrap that script into a shell (.sh) or bat (.bat) and run that when building.

PS: \x27is a scape for the single quote. sed command would mix the single quotes with the strings you are replacing.

You can find more about sed here: https://www.geeksforgeeks.org/sed-command-in-linux-unix-with-examples/

With a few shell commands you can use environment variables to do that in a script.

Hope that helps!

Answer 2

This works fine for me. Here's my test project file in its entirety:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net6.0;net48</TargetFrameworks>
  </PropertyGroup>
  <PropertyGroup Condition="'$(TargetFramework)'=='net6.0'">
    <AssemblyName>$(MSBuildProjectName).Core</AssemblyName>
  </PropertyGroup>
</Project>

I built with dotnet build -bl and then looked at the msbuild.binlog files using https://msbuildlog.com/. I see the top-level build kicking off two inner builds, one with each target framework:

If I look up higher in the viewer, I can see the evaluation for the inner build (id 109 as shown in the screenshot above) showing that the value was updated during evaluation:

If I were you, I'd get a binlog and see if the property is being reassigned again back to the default, perhaps by another .targets file later on.

Answer 3

So I determined that even if I got the assembly renamed the way Jimmy was able to show, it could still cause issues when I do this with our full solution (that has a ton of dependencies) -- I'm not confident Visual Studio will be able to find my renamed Core assemblies when resolving the dependencies (since they're project dependencies).

So here's what I did..

1. I created 4 build configurations: DebugFramework, DebugNET, ReleaseFramework, and ReleaseNET.

2. I removed the TargetFramework from the PropertyGroup.

3. I added this to each project file:

    <Choose>    
        <When Condition="'$(Configuration)' == 'DebugNET' OR '$(Configuration)' == 'ReleaseNET'">
            <PropertyGroup>
                <TargetFramework>net6.0-windows</TargetFramework>
                <AssemblyName>$(MSBuildProjectName).Core</AssemblyName>
            </PropertyGroup>
        </When>
        <Otherwise>
            <PropertyGroup>
                <TargetFramework>net48</TargetFramework>
                <AssemblyName>$(MSBuildProjectName)</AssemblyName>
            </PropertyGroup>
        </Otherwise>
    </Choose>
   

Now, when I build, the AssemblyName is known at the start of the build and doesn't change in the middle.

While I'd rather have both .NET and .FRAMEWORK builds performed at the same time, this workaround is good enough, and is probably more like the way Microsoft intended us to do it in the first place.

Hope this helps someone else. Thanks for everyone's input!