Generating strongly typed resource files requires non-intuitive addition of properties #4751

bergmeister · 2019-09-19T20:53:50Z

Steps to reproduce

git clone https://github.com/PowerShell/PSScriptanalyzer
rm global.json # so that the latest version (3.0) of the SDK is used and not 2.2
cd Engine
dotnet build # should work
rm Strings.Designer.cs
dotnet build # does not work

Expected behavior

Build works

Actual behavior

Build fails due to errors resulting from Strings.Designer.cs not being created.

It seems one needs to apply the following non-intuitive changes to the Engine.csproj:

-  <ItemGroup>
-     <Compile Update="Strings.Designer.cs">
-       <DesignTime>True</DesignTime>
-       <AutoGen>True</AutoGen>
-       <DependentUpon>Strings.resx</DependentUpon>
-     </Compile>
-  </ItemGroup>
 
   <ItemGroup>
     <EmbeddedResource Update="Strings.resx">
-       <Generator>ResXFileCodeGenerator</Generator>
+       <Generator>MSBuild:Compile</Generator><!-- Tell Visual Studio to run a build if the resx file changes -->
-      <LastGenOutput>Strings.Designer.cs</LastGenOutput>
+      <StronglyTypedFileName>$(IntermediateOutputPath)\Strings.Designer.cs</StronglyTypedFileName>
+      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
+      <StronglyTypedNamespace>Microsoft.Windows.PowerShell.ScriptAnalyzer</StronglyTypedNamespace>
+      <StronglyTypedClassName>Strings</StronglyTypedClassName>
     </EmbeddedResource>
   </ItemGroup>

+  <!-- For VS Code/OmniSharp support, ensure that CoreResGen runs before CoreCompile -->
+  <PropertyGroup>
+    <CoreCompileDependsOn>PrepareResources;$(CompileDependsOn)</CoreCompileDependsOn>
+  </PropertyGroup>

The StronglyTypedNamespace is due to the following in the csproj: <RootNamespace>Microsoft.Windows.PowerShell.ScriptAnalyzer</RootNamespace>
However, having to supply all the other additional parameters seems unintuitive. I'd like to see a minimal solution for a csproj that also works with VS btw.

Environment data

msbuild /version output:

OS info:

Windows 10 1809
.Net Core 3.0-rc1

The text was updated successfully, but these errors were encountered:

rainersigwald · 2019-09-23T20:22:20Z

Team triage: I'd like to dig in on some of the changes required here. This may turn into an SDK feature to make it easier to get strongly typed resources.

bergmeister · 2019-09-23T20:33:38Z

Yes, please, ideally the csproj should just pick it up automatically via convention over configuration if the resx file name matches the csproj name.
Please make sure it works both from commandline and VS

bergmeister · 2019-10-04T22:57:42Z

@rainersigwald Any updates? Building using dotnet build works now with the described scenario but both VS and VS-Code get confused and show compiler warnings and errors (VS-Code somehow sees the class name as ambiguous and VS fails to build). Also, at runtime, I get the following exception:

MissingManifestResourceException: Could not find the resource "Strings.resources" among the resources "Engine.Strings.resources" embedded in the assembly "Microsoft.Windows.PowerShell.ScriptAnalyzer", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.

I created the following branch with my changes: https://github.com/bergmeister/PSScriptAnalyzer/tree/netcore3_resgen

bergmeister · 2019-11-19T19:28:26Z

Any updates @rainersigwald ? This would be good to be fixed in 3.1 as it will be LTS

iSazonov · 2020-04-14T16:43:04Z

I am trying to move PowerShell Core projects to the generator.
With @rainersigwald sample I was able to compile most of csproj-s but not last with UseWPF enabled.
With True resources do not generated at all if added.

iSazonov · 2020-04-18T07:43:57Z

I could be able compile PowerShell Core with some workarounds. See PowerShell/PowerShell#12355

tillig · 2020-08-05T18:43:52Z

I was successful for a while doing this:

  <ItemGroup>
      <EmbeddedResource Update="TracerMessages.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>TracerMessages.Designer.cs</LastGenOutput>
      <StronglyTypedFileName>TracerMessages.Designer.cs</StronglyTypedFileName>
      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
      <StronglyTypedNamespace>Autofac.Diagnostics.DotGraph</StronglyTypedNamespace>
      <StronglyTypedClassName>TracerMessages</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>

Note the LastGenOutput and StronglyTypedFileName match. Unfortunately in a recent .NET Core SDK update (I'm now running 3.1.302 on Mac) this started yielding a CS2002 warning:

CSC : warning CS2002: Source file 'TracerMessages.Designer.cs' specified multiple times [/Users/tillig/dev/autofac/Autofac.Diagnostics.DotGraph/src/Autofac.Diagnostics.DotGraph/Autofac.Diagnostics.DotGraph.csproj]

The only way to work around it was to remove the checked-in Designer.cs file and switch to the $(IntermediatePath) in the StronglyTypedFileName as seen in the initial issue comment.

  <ItemGroup>
    <EmbeddedResource Update="TracerMessages.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>TracerMessages.Designer.cs</LastGenOutput>
      <StronglyTypedFileName>$(IntermediateOutputPath)/TracerMessages.Designer.cs</StronglyTypedFileName>
      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
      <StronglyTypedNamespace>Autofac.Diagnostics.DotGraph</StronglyTypedNamespace>
      <StronglyTypedClassName>TracerMessages</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>

This issue is the only place I've found any of this documented. It'd be nice if this was more straightforward to work with in a non-Visual-Studio (i.e., VS Code / all-command-line) environment.

yinzara · 2021-08-17T21:06:39Z

I was successful for a while doing this:
  <ItemGroup>
      <EmbeddedResource Update="TracerMessages.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>TracerMessages.Designer.cs</LastGenOutput>
      <StronglyTypedFileName>TracerMessages.Designer.cs</StronglyTypedFileName>
      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
      <StronglyTypedNamespace>Autofac.Diagnostics.DotGraph</StronglyTypedNamespace>
      <StronglyTypedClassName>TracerMessages</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>
Note the LastGenOutput and StronglyTypedFileName match. Unfortunately in a recent .NET Core SDK update (I'm now running 3.1.302 on Mac) this started yielding a CS2002 warning:

CSC : warning CS2002: Source file 'TracerMessages.Designer.cs' specified multiple times [/Users/tillig/dev/autofac/Autofac.Diagnostics.DotGraph/src/Autofac.Diagnostics.DotGraph/Autofac.Diagnostics.DotGraph.csproj]

The only way to work around it was to remove the checked-in Designer.cs file and switch to the $(IntermediatePath) in the StronglyTypedFileName as seen in the initial issue comment.
  <ItemGroup>
    <EmbeddedResource Update="TracerMessages.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>TracerMessages.Designer.cs</LastGenOutput>
      <StronglyTypedFileName>$(IntermediateOutputPath)/TracerMessages.Designer.cs</StronglyTypedFileName>
      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
      <StronglyTypedNamespace>Autofac.Diagnostics.DotGraph</StronglyTypedNamespace>
      <StronglyTypedClassName>TracerMessages</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>
This issue is the only place I've found any of this documented. It'd be nice if this was more straightforward to work with in a non-Visual-Studio (i.e., VS Code / all-command-line) environment.

While this solution removes the warning on running dotnet build and project compiles normally, it then makes Visual Studio Code show errors in the places that used the strongly typed generated class indicating that it can't be found.

Is there no other workaround?

archive11 · 2021-11-12T19:50:56Z

I was successful for a while doing this:
  <ItemGroup>
      <EmbeddedResource Update="TracerMessages.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>TracerMessages.Designer.cs</LastGenOutput>
      <StronglyTypedFileName>TracerMessages.Designer.cs</StronglyTypedFileName>
      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
      <StronglyTypedNamespace>Autofac.Diagnostics.DotGraph</StronglyTypedNamespace>
      <StronglyTypedClassName>TracerMessages</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>
Note the LastGenOutput and StronglyTypedFileName match. Unfortunately in a recent .NET Core SDK update (I'm now running 3.1.302 on Mac) this started yielding a CS2002 warning:
CSC : warning CS2002: Source file 'TracerMessages.Designer.cs' specified multiple times [/Users/tillig/dev/autofac/Autofac.Diagnostics.DotGraph/src/Autofac.Diagnostics.DotGraph/Autofac.Diagnostics.DotGraph.csproj]
The only way to work around it was to remove the checked-in Designer.cs file and switch to the $(IntermediatePath) in the StronglyTypedFileName as seen in the initial issue comment.
  <ItemGroup>
    <EmbeddedResource Update="TracerMessages.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>TracerMessages.Designer.cs</LastGenOutput>
      <StronglyTypedFileName>$(IntermediateOutputPath)/TracerMessages.Designer.cs</StronglyTypedFileName>
      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
      <StronglyTypedNamespace>Autofac.Diagnostics.DotGraph</StronglyTypedNamespace>
      <StronglyTypedClassName>TracerMessages</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>
This issue is the only place I've found any of this documented. It'd be nice if this was more straightforward to work with in a non-Visual-Studio (i.e., VS Code / all-command-line) environment.
While this solution removes the warning on running dotnet build and project compiles normally, it then makes Visual Studio Code show errors in the places that used the strongly typed generated class indicating that it can't be found.

Is there no other workaround?

Try changing $(IntermediateOutputPath) to:
<StronglyTypedFileName>Properties/Something.Designer.cs</StronglyTypedFileName>.

yinzara · 2022-04-28T23:42:30Z

I was successful for a while doing this:
  <ItemGroup>
      <EmbeddedResource Update="TracerMessages.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>TracerMessages.Designer.cs</LastGenOutput>
      <StronglyTypedFileName>TracerMessages.Designer.cs</StronglyTypedFileName>
      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
      <StronglyTypedNamespace>Autofac.Diagnostics.DotGraph</StronglyTypedNamespace>
      <StronglyTypedClassName>TracerMessages</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>
Note the LastGenOutput and StronglyTypedFileName match. Unfortunately in a recent .NET Core SDK update (I'm now running 3.1.302 on Mac) this started yielding a CS2002 warning:
CSC : warning CS2002: Source file 'TracerMessages.Designer.cs' specified multiple times [/Users/tillig/dev/autofac/Autofac.Diagnostics.DotGraph/src/Autofac.Diagnostics.DotGraph/Autofac.Diagnostics.DotGraph.csproj]
The only way to work around it was to remove the checked-in Designer.cs file and switch to the $(IntermediatePath) in the StronglyTypedFileName as seen in the initial issue comment.
  <ItemGroup>
    <EmbeddedResource Update="TracerMessages.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>TracerMessages.Designer.cs</LastGenOutput>
      <StronglyTypedFileName>$(IntermediateOutputPath)/TracerMessages.Designer.cs</StronglyTypedFileName>
      <StronglyTypedLanguage>CSharp</StronglyTypedLanguage>
      <StronglyTypedNamespace>Autofac.Diagnostics.DotGraph</StronglyTypedNamespace>
      <StronglyTypedClassName>TracerMessages</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>
This issue is the only place I've found any of this documented. It'd be nice if this was more straightforward to work with in a non-Visual-Studio (i.e., VS Code / all-command-line) environment.
While this solution removes the warning on running dotnet build and project compiles normally, it then makes Visual Studio Code show errors in the places that used the strongly typed generated class indicating that it can't be found.
Is there no other workaround?
Try changing $(IntermediateOutputPath) to: <StronglyTypedFileName>Properties/Something.Designer.cs</StronglyTypedFileName>.

That will again cause the CSC : warning CS2002: Source file 'Properties/Something.Designer.cs' specified multiple times error again.

yinzara · 2022-04-28T23:53:19Z

I think this issue should probably be renamed and escalated.

There is currently no method to have some developers use VSCode and some developers use Visual Studio on the same codebase and still use "resx" files.

They are just simply incompatible.

VisualStudio will attempt to overwrite the designer files whenever it feels like it and those updated designer files will always be different than what the ResXFileCodeGenerator produces (it has a version in it that it doesn't normally).
They will always be in the same location as the resx file itself and there is no way to change the behavior Visual Studio.

The suggested work around in this issue won't work in that case either as VS will always generate the files next to the resx causing this issue.

Unfortunately this is a problem spread across three different projects with inconsistent behavior leading me to believe they will never get fixed unless they all just duplicate the behavior of VisualStudio

danjagnow · 2022-10-04T17:59:30Z

There's a nice write-up of this issue by @tillig at https://www.paraesthesia.com/archive/2022/09/30/strongly-typed-resources-with-net-core/. It would be good to see an SDK feature for this to get simple, consistent behavior in Visual Studio and VS Code.

Arthri · 2022-10-05T13:04:29Z

There's a nice write-up of this issue by @tillig at https://www.paraesthesia.com/archive/2022/09/30/strongly-typed-resources-with-net-core/. It would be good to see an SDK feature for this to get simple, consistent behavior in Visual Studio and VS Code.

I'll add to this. Changing the line <Generator>ResXFileCodeGenerator</Generator> to <Generator>MSBuild:Compile</Generator> then adding <CoreCompileDependsOn>PrepareResources;$(CompileDependsOn)</CoreCompileDependsOn> in the properties fully delegates the job to MSBuild and prevents conflicts with Visual Studio

tillig · 2022-10-25T14:35:17Z

I updated my blog article with the info from @Arthri - thanks! https://www.paraesthesia.com/archive/2022/09/30/strongly-typed-resources-with-net-core/

I wonder if it'd be interesting/helpful to have some sort of "current workaround" complete code example pinned in here somehow. It's really hard to mentally apply all the incremental changes/updates noted here to get to a "complete solution" that works. (Which, I guess, is the whole point of this issue, but scrolling through this issue is almost as hard as the issue itself.)

rainersigwald · 2022-10-25T14:39:21Z

@tillig I updated the OP with @Arthri's changes.

bergmeister · 2022-10-27T11:21:35Z

Thanks for the updates. I now have a PR open that makes it work, which I am very happy about. However, there is a difference between the update of @rainersigwald and the blog post by @tillig , which is the LastGenOutput part. Can you advise what this does and what considerations to make whether to use it or not please?

rainersigwald · 2022-10-27T13:35:25Z

LastGenOutput is not used by the build itself, and I believe it can be dropped now, but there may be some Visual Studio scenario where it is relevant--nothing stood out to me from a quick search of the internal codebase but that's not a guarantee. I'd leave it out and wait for further information myself, but I don't know what harm it would cause to leave it in.

jnm2 · 2022-10-27T14:42:52Z

I've been leaving LastGenOutput and other boilerplate there for the reason that the VS resx designer will reinsert it anyway on each save, and I don't want to have to undo .csproj changes each time. (Same with the .settings designer.) I haven't tried this MSBuild:Compile generator yet though.

mhutch · 2022-11-01T21:23:52Z

FWIW, Arcade has a solution for this (used by MSBuild itself AFAICT) which further points at dotnet/sdk#94 as an existing issue tracking this problem.

rainersigwald · 2022-11-02T12:57:09Z

@mhutch, MSBuild itself does not use the Arcade reimplementation (in fact we do not use strongly typed resources at all).

I believe the Arcade reimplementation of the MSBuild feature was done because its authors were unaware of the MSBuild feature.

mhutch · 2022-11-02T18:42:03Z

@mhutch, MSBuild itself does not use the Arcade reimplementation (in fact we do not use strongly typed resources at all).

msbuild/src/Directory.Build.targets

Line 113 in 9f03900

    
           <Target Name="SetResourceProperties" BeforeTargets="_GetEmbeddedResourcesWithSourceGeneration">

rainersigwald · 2022-11-02T18:48:17Z

Ah you're right, we had to do that to consume a source package that requires the Arcade approach. That's a bug in the package IMO.

kzu · 2023-04-10T07:01:11Z

Expanded on @tillig's approach and made it a general-purpose drop-in for Directory.Build.targets:

<Project>
  <PropertyGroup>
    <!-- For VSCode/Razor compat -->
    <CoreCompileDependsOn>PrepareResources;$(CoreCompileDependsOn)</CoreCompileDependsOn>
  </PropertyGroup>

  <ItemGroup>
    <EmbeddedResource Update="@(EmbeddedResource)">
      <Generator>MSBuild:Compile</Generator>
      <StronglyTypedFileName>$(IntermediateOutputPath)\$([MSBuild]::ValueOrDefault('%(RelativeDir)', '').Replace('\', '.').Replace('/', '.'))%(Filename).g$(DefaultLanguageSourceExtension)</StronglyTypedFileName>
      <StronglyTypedLanguage>$(Language)</StronglyTypedLanguage>
      <StronglyTypedNamespace Condition="'%(RelativeDir)' == ''">$(RootNamespace)</StronglyTypedNamespace>
      <StronglyTypedNamespace Condition="'%(RelativeDir)' != ''">$(RootNamespace).$([MSBuild]::ValueOrDefault('%(RelativeDir)', '').Replace('\', '.').Replace('/', '.').TrimEnd('.'))</StronglyTypedNamespace>
      <StronglyTypedClassName>%(Filename)</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>
</Project>

Arthri · 2023-04-12T13:22:47Z

Expanded on @tillig's approach and made it a general-purpose drop-in for Directory.Build.targets:

<Project>
  <PropertyGroup>
    <!-- For VSCode/Razor compat -->
    <CoreCompileDependsOn>PrepareResources;$(CoreCompileDependsOn)</CoreCompileDependsOn>
  </PropertyGroup>

  <ItemGroup>
    <EmbeddedResource Update="@(EmbeddedResource)">
      <Generator>MSBuild:Compile</Generator>
      <StronglyTypedFileName>$(IntermediateOutputPath)\$([MSBuild]::ValueOrDefault('%(RelativeDir)', '').Replace('\', '.').Replace('/', '.'))%(Filename).g$(DefaultLanguageSourceExtension)</StronglyTypedFileName>
      <StronglyTypedLanguage>$(Language)</StronglyTypedLanguage>
      <StronglyTypedNamespace Condition="'%(RelativeDir)' == ''">$(RootNamespace)</StronglyTypedNamespace>
      <StronglyTypedNamespace Condition="'%(RelativeDir)' != ''">$(RootNamespace).$([MSBuild]::ValueOrDefault('%(RelativeDir)', '').Replace('\', '.').Replace('/', '.').TrimEnd('.'))</StronglyTypedNamespace>
      <StronglyTypedClassName>%(Filename)</StronglyTypedClassName>
    </EmbeddedResource>
  </ItemGroup>
</Project>

I believe this generates classes for Resources.en-US.resx along with Resources.resx which might not be intended

mhutch · 2023-05-26T02:29:50Z

<CoreCompileDependsOn>PrepareResources;$(CoreCompileDependsOn)</CoreCompileDependsOn>

FWIW, this seems to cause a recursive overflow in the inner markup build when UseWpf is true.

Difegue · 2023-09-04T16:30:08Z

<CoreCompileDependsOn>PrepareResources;$(CoreCompileDependsOn)</CoreCompileDependsOn>
FWIW, this seems to cause a recursive overflow in the inner markup build when UseWpf is true.

Can confirm - I've circumvented the recursion by calling PrepareResources as an InitialTarget instead:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop" InitialTargets="PrepareResources">

But I end up with the CS2002 errors mentioned previously so it likely doesn't actually work 🫠

Arthri · 2023-09-05T04:09:08Z

Does removing it work? I suspect WPF already has a similar setting

ArchibaldMacdonald-cyacomb · 2024-08-07T16:53:33Z

Is there any solution to this for WPF projects?

ArchibaldMacdonald-cyacomb · 2024-08-07T18:22:22Z

I managed to get WPF projects building via:

  <PropertyGroup Condition="'$(UseWPF)' == 'true'">
    <!-- Ensure WPF apps generate RESX designer files with namespace not taken from wpftmp file. --> 
    <RootNamespace Condition="$(RootNamespace.EndsWith('_wpftmp'))">$(_TargetAssemblyProjectName)</RootNamespace>
    <!-- Ensure WPF apps invoke the RESX generator -->
    <CoreCompileDependsOn>$(CoreCompileDependsOn);SplitResourcesByCulture;CreateManifestResourceNames;CoreResGen</CoreCompileDependsOn>
  </PropertyGroup>

jansohn · 2024-11-05T09:23:29Z

It is really quite tricky to get this right, especially with WPF involved. Are there any intentions to make this work "out-of-the-box"?

I've put together a small sample project (with multiple language files and WPF) for reference / reproduction which might help in resolving this issue.

kzu · 2024-11-07T12:50:58Z

I have updated the blog post with my current approach that improves on this:

Take smaller compile dependency: <CoreCompileDependsOn>CoreResGen;$(CoreCompileDependsOn)</CoreCompileDependsOn>
Generate strong-typed class only for <EmbeddedResource > items you've specified MSBuild:Compile as the custom tool/generator metadata (manually in the proj or via the toolwindow). Such as:

  <ItemGroup>
    <EmbeddedResource Update="Strings.resx">
      <Generator>MSBuild:Compile</Generator>
    </EmbeddedResource>
  </ItemGroup>

And here's a sample repo showcasing it: https://github.com/[kzu/Resources.Wpf](https://github.com/kzu/Resources.Wpf)

georg-jung · 2025-01-10T17:01:39Z

Thanks @kzu for sharing!

In my project I have a lot of resx files but not so much locales. Thus, your approach can be combined with e.g.

<ItemGroup>
  <NonLocalizedResx Include="Resources\**\*.resx" Exclude="Resources\**\*.de.resx;Resources\**\*.en.resx"/>
  <EmbeddedResource Update="@(NonLocalizedResx)">
    <Generator>MSBuild:Compile</Generator>
  </EmbeddedResource>
</ItemGroup>

(If all resx inside ./Resources should have a strongly typed resource class generated and en and de are your only locales.)

Note: I added this directly to my project's csproj, not the Directory.build.targets.

As I use these resources in combination with DisplayAttribute, adding <PublicClass> to the Directory.build.targets was also helpful:

<EmbeddedResource Update="@(EmbeddedResource -> WithMetadataValue('Generator', 'MSBuild:Compile'))" Type="Resx">
  <StronglyTypedFileName>$(IntermediateOutputPath)\$([MSBuild]::ValueOrDefault('%(RelativeDir)', '').Replace('\', '.').Replace('/', '.'))%(Filename).g$(DefaultLanguageSourceExtension)</StronglyTypedFileName>
  <StronglyTypedLanguage>$(Language)</StronglyTypedLanguage>
  <StronglyTypedNamespace Condition="'%(RelativeDir)' == ''">$(RootNamespace)</StronglyTypedNamespace>
  <StronglyTypedNamespace Condition="'%(RelativeDir)' != ''">$(RootNamespace).$([MSBuild]::ValueOrDefault('%(RelativeDir)', '').Replace('\', '.').Replace('/', '.').TrimEnd('.'))</StronglyTypedNamespace>
  <StronglyTypedClassName>%(Filename)</StronglyTypedClassName>
  <PublicClass>true</PublicClass>
</EmbeddedResource>

… any IDE. This is admittedly not very intuitive, which is a known issue: dotnet/msbuild#4751. Also regenerate the Resources.Designer.cs files accordingly.

… any IDE. (#22386) This is admittedly not very intuitive, which is a known issue: dotnet/msbuild#4751. Also regenerate the Resources.Designer.cs files accordingly.

rainersigwald self-assigned this Sep 23, 2019

rainersigwald added this to the MSBuild 16.4 milestone Sep 23, 2019

rainersigwald added the Area: Task: GenerateResource Problems with the task itself, resgen.exe, and resx resources in general. label Sep 23, 2019

rainersigwald modified the milestones: MSBuild 16.4, Discussion Oct 7, 2019

iSazonov mentioned this issue Apr 18, 2020

Use dotnet strong typed resource builder PowerShell/PowerShell#12355

Closed

14 tasks

tillig added a commit to autofac/Autofac that referenced this issue Jul 13, 2020

Enable TracerMessages generation based on dotnet/msbuild#4751

9ad6a0d

marcpopMSFT modified the milestones: Discussion, 17.0 May 18, 2021

marcpopMSFT modified the milestones: 17.0, MSBuild 17.1 Jul 9, 2021

Forgind mentioned this issue Jul 14, 2021

Strongly Typed Resource - Custom Designer.cs #6109

Closed

marcpopMSFT modified the milestones: VS 17.1, VS 17.2 Dec 6, 2021

marcpopMSFT modified the milestones: VS 17.2, Backlog Jan 7, 2022

yinzara mentioned this issue May 9, 2022

CSC : error CS2002: Source file specified multiple times cannot be "NoWarn"ed #7609

Closed

tillig mentioned this issue Oct 24, 2022

CS2002 warning for .resx code generation in .NET Core / VS Code #8086

Closed

bergmeister mentioned this issue Oct 27, 2022

Generate strongly typed resources as part of build PowerShell/PSScriptAnalyzer#1855

Merged

6 tasks

rainersigwald mentioned this issue Nov 2, 2022

Switch to build-time generation for Resx Files dotnet/sdk#94

Open

rainersigwald mentioned this issue Feb 28, 2023

Added codes to messages dotnet/sdk-container-builds#357

Merged

al-kau mentioned this issue Apr 10, 2023

Add Microsoft.Extensions.Hosting Eppie-io/Eppie-CLI#6

Merged

KalleOlaviNiemitalo mentioned this issue Oct 30, 2023

[Feature Request]: ResGen.exe should have an option to generate partial classes #9369

Open

rolfbjarne mentioned this issue Mar 13, 2025

[rgen] Update generated resources during the build instead of through any IDE. dotnet/macios#22386

Merged

Generating strongly typed resource files requires non-intuitive addition of properties #4751

Generating strongly typed resource files requires non-intuitive addition of properties #4751

Comments

bergmeister commented Sep 19, 2019 • edited by rainersigwald Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Steps to reproduce

Expected behavior

Actual behavior

Environment data

rainersigwald commented Sep 23, 2019

Uh oh!

bergmeister commented Sep 23, 2019

Uh oh!

bergmeister commented Oct 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bergmeister commented Nov 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iSazonov commented Apr 14, 2020

Uh oh!

iSazonov commented Apr 18, 2020

Uh oh!

tillig commented Aug 5, 2020

Uh oh!

yinzara commented Aug 17, 2021

Uh oh!

archive11 commented Nov 12, 2021

Uh oh!

yinzara commented Apr 28, 2022

Uh oh!

yinzara commented Apr 28, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danjagnow commented Oct 4, 2022

Uh oh!

Arthri commented Oct 5, 2022

Uh oh!

tillig commented Oct 25, 2022

Uh oh!

rainersigwald commented Oct 25, 2022

Uh oh!

bergmeister commented Oct 27, 2022

Uh oh!

rainersigwald commented Oct 27, 2022

Uh oh!

jnm2 commented Oct 27, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mhutch commented Nov 1, 2022

Uh oh!

rainersigwald commented Nov 2, 2022

Uh oh!

mhutch commented Nov 2, 2022

Uh oh!

rainersigwald commented Nov 2, 2022

Uh oh!

kzu commented Apr 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Arthri commented Apr 12, 2023

Uh oh!

mhutch commented May 26, 2023

Uh oh!

Difegue commented Sep 4, 2023

Uh oh!

Arthri commented Sep 5, 2023

Uh oh!

ArchibaldMacdonald-cyacomb commented Aug 7, 2024

Uh oh!

ArchibaldMacdonald-cyacomb commented Aug 7, 2024

Uh oh!

jansohn commented Nov 5, 2024

Uh oh!

kzu commented Nov 7, 2024

Uh oh!

georg-jung commented Jan 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bergmeister commented Sep 19, 2019 •

edited by rainersigwald

Loading

bergmeister commented Oct 4, 2019 •

edited

Loading

bergmeister commented Nov 19, 2019 •

edited

Loading

yinzara commented Apr 28, 2022 •

edited

Loading

jnm2 commented Oct 27, 2022 •

edited

Loading

kzu commented Apr 10, 2023 •

edited

Loading

georg-jung commented Jan 10, 2025 •

edited

Loading