[Hot Reload] ENC0003: Updating 'attribute' requires restarting the application caused by AssemblyInformationalVersionAttribute

[jeromelaban]

Describe the bug

During Hot Reload, with .NET 7 or .NET 8, building WPF (or Uno Platform) app and hot reloading it in VS 2022 (17.7 or 17.8) can produce the following error:

MyApp.AssemlyInfo.cs (line 17): error ENC0003: Updating 'attribute' requires restarting the application.

Where the generated file is

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
 
using System;
using System.Reflection;
 
[assembly: System.Reflection.AssemblyCompanyAttribute("test")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0")]
[assembly: System.Reflection.AssemblyProductAttribute("test")]
[assembly: System.Reflection.AssemblyTitleAttribute("test")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")]

Line 17 being:

[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0")]

Having tried to debug this issue, if feels like the Roslyn HotReload workspace is, for some reason, generating a AssemblyInformationalVersionAttribute sometimes:

sdk/src/BuiltInTools/dotnet-watch/HotReload/CompilationHandler.cs

Line 69 in 6710347

var project = await _workspace.OpenProjectAsync(context.FileSet.Project.ProjectPath, cancellationToken: cancellationToken);

but since there's no way to get binlogs for the workspace's solution load, it's difficult to troubleshoot why the original value and the hotreloaded values may be different.

To Reproduce

The part being unclear is the set of conditions for this to happen, but here's a summary:

1. Create a WPF app
2. Hot reload it
3. Stop the hot reload completely by stopping the app
4. Start the hot reload session again

Workaround

Disabling assemblyversion generation helps:

<GenerateAssemblyInfo Condition="'$(Configuration)'=='Debug'">false</GenerateAssemblyInfo>

But can cause CA1416 to appear. Disabling AssemblyFileVersionAttribute and AssemblyInformationalVersionAttribute can also help as more precise:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets

Line 75 in 6710347

<Target Name="GetAssemblyAttributes"

Further technical details

Versions

• .NET 7.0.403 or .NET 8.0.100 RC2
• VS 17.7.6 or VS 17.8 Preview 6

[baronfel]

This might be related to Sourcelink being on by default in .Net 8 SDKs - it would impact the value in the AssemblyInformationalVersion if git commits were being made between hot reload refreshes.

[KalleOlaviNiemitalo]

If this were a matter of new Git commits, then I'd expect the generated file to include some commit ID, rather than just AssemblyInformationalVersionAttribute("1.0.0").

[baronfel]

If this were a matter of new Git commits, then I'd expect the generated file to include some commit ID, rather than just AssemblyInformationalVersionAttribute("1.0.0").

Good call - I'm just a little sensitive to potentially SourceLink-related regressions, since we've seen a few of those in the latter part of this release.

[jeromelaban]

@KalleOlaviNiemitalo it may be so, the file you're seeing here may be one of the updated versions for that file (original or updated). That's the problem of generated files on disk by msbuild, they get re-generated by both VS and the hot reload workspace.

[jeromelaban]

Reading further about this SourceControlInformationFeatureSupported, it looks like this is set by VS in the environment. Is it something that should be propagated to the HR workspace as well?

[jeromelaban]

Ok, so thanks to your insights, I now have a reliable repro:

• Create a net8.0 WPF app
• Create a class library referenced by the WPF app, use code from the library in the WPF app project
• Add both to a git repository for the solution's folder, and commit the files.
• Build the app once
• Open the obj\Debug\net8.0\MyLibrary.AssemblyInfo.cs, notice the Commit ID in AssemblyInformationalVersionAttribute
• Start the app
• Make an update to code in the class library, hot reload it
• Notice that the AssemblyInformationalVersionAttribute does not contain the ID anymore and fails with ENC0003

[tmat]

@jeromelaban I followed the steps above but can't repro :(. The attribute is not changed, still contains the commit SHA.

[tmat]

@jeromelaban Could you please capture and share the binary logs for design time build?

See https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Providing-Binary-Logs.md#capturing-binary-logs-through-visual-studio

When setting env variables before starting VS following the above instructions, could you also set

set Microsoft_CodeAnalysis_EditAndContinue_LogDir=%TEMP%\enclog

and share the content?

[SkinnySackboy]

MSBuildReproLogs.zip

@tmat Also experiencing this issue having update to the latest version of Visual Studio 17.8. .NET 7.0 WPF. I have attached my binary logs.

The workaround suggested by @jeromelaban works but is pretty invasive to update all our projects in all our solutions.

For reference, this is the popup I see:

[AlexKeene]

I am also intermittently experiencing this issue whilst debugging my Asp.Net Core 7 application in Visual Studio 17.8.0.

Resuming after a breakpoint triggers a hot reload which fails with ENC0003 even though I have not made any code changes to warrant a reload.

Logs attached, the change seems to involve something updating from (or to?):

[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.3.6.0")]

to

[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.3.6.0+204d3a2ffe53f0ee68a48dd18f875d0dcf0663d0")]

in my AssemblyInfo file.

Version info in my .csproj is

<AssemblyVersion>1.3.6.0</AssemblyVersion>
<FileVersion>1.3.6.0</FileVersion>
<Version>1.3.6.0</Version>

MSBuildReproLogs.zip

[tmat]

@SkinnySackboy Unrelated but FYI, the build logs show error:

...\git\svrace\packages\WiX.Toolset.3.8.1128.0\tools\wix\wix2010.targets(539,5): error WIXTARGETS100: The OutputName property is not set in project "SVRace.Setup.wixproj". The OutputName defines the name of the output without a file extension. Please set this in the project file before the <Import> of the wix.targets file. [...\git\svrace\src\SVRace.Setup\SVRace.Setup.wixproj]

[tmat]

I found the problem. A workaround is to set EnableSourceControlManagerQueries to true globally (for all projects in the repo), e.g. add Directory.Build.props to the source root with:

<Project>
  <PropertyGroup>
    <EnableSourceControlManagerQueries>true</EnableSourceControlManagerQueries>
  </PropertyGroup>
</Project>

@AlexKeene @SkinnySackboy Could you please try this workaround and confirm it works for you? Thanks!

[pvginkel]

I had the same issue and this work around resolves the issue for me.

[tmat]

@pvginkel Thanks for confirmation

[SkinnySackboy]

@tmat The WiX issue was unrelated but the EnableSourceControlManagerQueries setting seemed to do the trick, thanks!

[FutureAIGuru]

I have had this error since .NET 6. MS does nothing "unable to investigate further..." unless I debug it for them. Could you please go to the MS Developer Community in places like this: https://developercommunity.visualstudio.com/t/What-is-the-CS8984-error-Hot-Reload-doe/10508225#T-ND10543272 (and several other places) and voice your concern. Perhaps you have a repeatable situation they can decipher.

[lsoft]

I see the same issue. Started after installing VS 17.8.

[lindexi]

I find this issues with VisualStudio 2022 17.9.0 and dotnet 8.0.200

[AArnott]

I'm hitting this too with VS 2022 Update 9.

[KirillOsenkov]

did this regress or was never properly fixed?

[AArnott]

ENC has appeared mostly broken for me for years. The last several months even F10 stepping fails sporadically without any edits at all, with the assembly attribute file(s) blamed as having changed when they haven't (though design-time builds maybe touched their timestamps).

[tmat]

@AArnott Whenever you have issue with ENC having this env variable set for VS process to collect detailed logs and sharing the logs will help fixing it:

set Microsoft_CodeAnalysis_EditAndContinue_LogDir=%TEMP%\enclog

You can keep it set for a while and use VS as usual, then delete the directory once in a while.

Feel free to ping me any time you have issue.

[Mgamerz]

Been seeing this a ton in VS 17.10.x. Makes hot reload almost impossible. I run the app, hit a breakpoint, step through a few, and when I click on continue to resume, it tells me that I deleted a bunch of fields (in files I haven't even opened) and then hot reload no longer works. Happens almost every single time for me.

[KirillOsenkov]

For everyone who's still seeing this, ensure that you use the latest version of the .NET SDK 8, as well as remove the package reference to Microsoft.SourceLink.*. SourceLink now comes in the SDK so you no longer need the PackageReference (e.g. Microsoft.SourceLink.AzureRepos.Git). Older versions of these packages have the incrementality bug which has been fixed in the SDK.

[AArnott]

@KirillOsenkov That's awesome. Does the SDK handle both GitHub and Azure Repos for source link purposes?

[KirillOsenkov]

I think so. I saw it work fine for Azure Repos. It's easy to check - if you have the Git SHA in the *.AssemblyInfo.cs in your obj, it means it works fine.

[tmat]

Yes, GitHub, Azure Repos, GitLab, and BitBucket are included in the box

https://github.com/dotnet/sdk/blob/main/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.SourceLink.props#L22-L29

[daiplusplus]

I'm experiencing this issue too, because I'm using <AssemblyAttributes Include="AssemblyMetadata"> in my .csproj to write the build date/time:

I'm running .NET 8 SDK 8.0.6 on Windows 10 x64 22H2.

	<ItemGroup>
		<AssemblyAttribute Include="System.Reflection.AssemblyMetadataAttribute">
			<_Parameter1>AssemblyDate</_Parameter1>
			<_Parameter1_TypeName>System.String</_Parameter1_TypeName>
			<_Parameter2>$([System.DateTime]::UtcNow.ToString("O"))</_Parameter2>
			<_Parameter2_TypeName>System.String</_Parameter2_TypeName>
		</AssemblyAttribute>
	</ItemGroup>

...now because DateTime.UtcNow is live, this means that any-and-every build (design-time or otherwise) is going to cause a write to \obj\net8.0\MyProject.AssemblyInfo.cs with different data, every time, which causes the ENC003 error.

...so I changed it to render a low-resolution timestamp when it's a DesignTimeBuild (24 hours should be enough time to debug, right?)

	<ItemGroup>
		<AssemblyAttribute Include="System.Reflection.AssemblyMetadataAttribute">
			<_Parameter1>AssemblyDate</_Parameter1>
			<_Parameter1_TypeName>System.String</_Parameter1_TypeName>
			<_Parameter2 Condition="( '$(DesignTimeBuild)' == 'true' ) Or  ( '$(Configuration)' == 'Debug' )">$([System.DateTime]::UtcNow.ToString("yyyy-MM-ddT00:00:00.0000000Z"))</_Parameter2>
			<_Parameter2 Condition="( '$(DesignTimeBuild)' != 'true' ) And ( '$(Configuration)' != 'Debug' )">$([System.DateTime]::UtcNow.ToString("O"))</_Parameter2>
			<_Parameter2_TypeName>System.String</_Parameter2_TypeName>
		</AssemblyAttribute>
	</ItemGroup>

...but I find that even with this change (and the resultant \obj\net8.0\MyProject.AssemblyInfo.cs file's text being unchanged), the file is still re-written to which triggers the ENC0003 error message.

..and if I start Debugging from a non-DesignTimeBuild then that, too, will see the AssemblyDate metadata attribute text change and trigger the error.

---

...but this feels like a new behaviour to me: I've been using this MSBuild <AssemblyAttribute> snippet for probably almost a decade now and I don't remember it being responsible for ENC errors in the past.

I'm asking if there's a way to have ENC work by ignoring any changes to ``\obj\net8.0\MyProject.AssemblyInfo.cs`.

I also seem to be the only person on the Internet with this problem - so there's a hint I'm doing something wrong without realizing it. Are there any better approaches to adding a Build Date+Timestamp to an assembly that doesn't break ENC?

[tmat]

Are there any better approaches to adding a Build Date+Timestamp to an assembly that doesn't break ENC?

What do you use the timestamp for?

[daiplusplus]

Are there any better approaches to adding a Build Date+Timestamp to an assembly that doesn't break ENC?

What do you use the timestamp for?

Currently, for two main reasons, and it's easy to think of a few more:

• Support triage: Build timestamps allow for instantly finding the age of some deployment which greatly speeds up problem triage: when a support ticket comes in with attached generated deployment info (which includes the baked-in build date+times); as it means we can instantly see if the build used is too "old" to be worth investigating any further until-and-unless the user updates to a more recent build).
  • Whereas when a support ticket comes in with only the git commit hash then someone has to manually look-up the git commit hash to see how old it was; or if it was a manual build made by someone on their machine or from a commit that was squashed/rebased or otherwise "lost" then there'd be zero information available at all.
  • SemVer is great and all, but doesn't cover parallel development branches and nontrivial software-configuration-management scenarios (but neither do build date+times by themselves, but it all helps to identify exactly where a built .NET assembly file came from).
• Log/Scratch folder naming: When we use filesystem logging, each new deployment gets a new directory name. Originally we used only the git commit hashes, but after a few dozen deployments without any cleanup of the directories it became hard to tell which log directories were stale or not because when sorted lexicographically by ls/dir/Explorer.exe they aren't sorted chronologically. By using an RFC 3339-formatted build date+time as the first part of the directory name (and then concatening with the git commit hash) it means anyone in the filesystem can tell which logging directories are stale/old/uninteresting.
• User education: For on-prem desktop-based applications, having the build-date available means we can notify them (unobtrusively!) that their installed software version is probably outdated and they might want to consider updating (especially when an automatic check-for-updates feature isn't possible, such as when for our software runs behind an air-gap and situations like that) - whereas the only alternative that comes to mind is checking the install date - but the install date doesn't help you if the user installed an ancient build yesterday and they're on the phone to us saying it can't possibly be an ancient build because the software says it's only a day-old.
• SemVer disambiguation: There's a minor ergonomic issue with the <Version> MSBuild property: if you leave the <Version> as-is in your source-control and forget to increment it or forget to add a -dev tag, then every build you make (especially locally) is going to have the same AssemblyVersion (or worse: NuGet package version) as the last build you made/released - and dealing with the consequences of a directory full of actually-different-but-identically-versioned assemblies is much harder without having build date+timestamps baked into the binaries (for the purposes of this argument, we can't trust the filesystem Last-Modified time; consider when you extract files from a zip archive or save email attachments, for examaple).

We do digitally-sign (AuthentiCode) most of our binaries, and we could get the signing-date (rather than the build date+time), but plenty of binaries and sometimes entire builds (especially builds made outside our CI+CD system and build-env) go without being code-signed (expediency is a legitimate reason), whereas build date+times can always be available in every build.