dotnet / project-system

The .NET Project System for Visual Studio
MIT License
959 stars 385 forks source link

Turning on code generation for resource files with cultures in their names results in an error #1553

Open davkean opened 7 years ago

davkean commented 7 years ago
  1. File -> New -> Console Application (.NET Core)
  2. Add New Resource called "Resource.en-US.resx

In the Error List:

Error       Custom tool PublicResXFileCodeGenerator failed to produce an output for input file 'Resource.en-US.resx' but did not log a specific error.  ConsoleApp181   c:\users\davkean\documents\visual studio 2017\Projects\ConsoleApp181\ConsoleApp181\Resource.en-US.resx  1   

Did some investigation - this appears to be (somewhat) by design by the code generator (seeResXFileCodeGenerator.GenerateCode) and has been it's behaviour since VS 2005 (yes 2005, not 2015). What is different in CPS though, is that it errors in this situation - whereas, the legacy project system outputs an empty source file.

Looking through the bug that caused them to implement this behavior was to avoid having both the neutral and the language-specific resource generate the same code and result in build errors. However, in some situations you don't have a neutral Resource file such as when your neutral resources end up in a satellite assembly. ie I don't think this behavior makes sense.

davkean commented 7 years ago

@nguerrera This was cause of your issue when you tried to do this.

davkean commented 7 years ago

Okay, thinking about this a little more I understand why they originally implemented this behavior - but I don't agree with the fix they made. Basically, they wanted to prevent the situation where you add multiple language-specific resources of the same resource file via Add Item, from getting code generated, as that will result in build errors.

Instead, I think we should fix this in a couple of ways:

  1. If it is a language-specific resource and the language-neutral one already exists, we shouldn't turn on code generation for it.
  2. We should let you specifically turn on code generation for it if you so want.
NiBoNocks commented 6 years ago

I also have this problem and unfortunately can not find a working solution for this! When I create a new project (.Net Core 2.0 Web application, Visual Studio 2017 Community, latest version) and follow the instructions of the site "https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization" (create resources directory and there for example a file "Resources / Models.ResTestModel.de.resx"), I always get the error message: "Custom tool ResXFileCodeGenerator failed to make an output for input file ... but did not log a specific error". I have tested it on different systems. This is obviously the case when the language identifier (".de") appears in the file name of the resource file. Files without language recognition seem to work! Can anyone offer a solution? I would be very grateful for this!

bill-call commented 6 years ago

For the sake of clarity, are we to understand that the work-around is to have a language-neutral .resx file in the same directory? If I understand @davkean correctly, this would cause the static class to be emitted, but would not prevent the error message for each .resx file that had a locale embedded in the file name, which is (sort of) okay, because the error itself is harmless, to the extent that it does not mean that your build is bad.

bill-call commented 6 years ago

Well, I tried the above. It does seem to stop the errors, and XXX.designer.cs does get generated for the neutral .resx file.

bill-call commented 6 years ago

Okay, for everybody playing along at home, let me see if I can summarize this:

If you do anything that causes ResXFileCodeGenerator to run (this happens if you create, modify or select for the first time a .resx file) when the target .resx file has a culture designator in the file name (it has a form like foo.en.resx or foo.en-US.resx), but you do not also have a culture-neutral .resx file of the same base name (foo.resx) in the same directory, then you will get this error. The error is correct, in that no class file was emitted, but it is wrong, in that it should not be an error. The fact that no class file was emitted is by design; the fact that this specific reason for not emitting it is now being flagged as an error is incorrect.

Absent a fix, we have two choices:

  1. We can create a (otherwise unecessary) culture-neutral .resx file, which will cause the class to be emitted and thus prevent the error. If you choose this option, you don't have to put any strings in the culture-neutral file, so long as you specify a DefaultRequestCulture that points to one of your culture-specific .resx files. However; if you need to localize elements of your Model, you will need this class, and you will need it to add all the string IDs you need to use in your Model, but you can still leave the values blank.

  2. We can just ignore the error, as it has no effect on the viability of the build.

In making the decision, it is important to understand that the "error" is merely flagging the fact that ResXFileCodeGenerator did not emit a class file. It is up to us to decide whether or not we care. Most of the time, particularly for a Asp.Net Core project, we don't care, but see the note above about localizing Model text.

If you are localizing Model values, do not put your resource files in a different directory. This is because the generated static class will be scoped (both class and properties) as internal, not public, and the localization logic in the model will not be able to see it.

You can still use a separate directory for your resource files, but you will either need to manually edit the resource class to give the IDs you care about public scope, or you will have to ensure that PublicResXFileCodeGenerator is used instead of ResXFileCodeGenerator. You can do that latter by opening the culture-neutral .resx file and setting the "Access Modifier" dropdown to "Public".

Update: the add-an-empty-culture-neutral-resx-file trick does not seem to work completely. If you modify a culture-specific .resx file, or if you manually run ResXFileCodeGenerator on it, you will still get the error.

MohammedNoureldin commented 6 years ago

Any news regarding this bug? Although it doesn't have an effect on building, it is still not ideal to always have 1..X errors in error list.

UPDATE: It is correct that this bug is just there until I restart Visual Studio? and then it disappears completely?

Legends commented 6 years ago

Ooooh my, even resources files are rendered useless, don't even want to think about digging deeper into ASP.NET Core 2.0.... Back to MVC 5... until ASP.NET Core v6 perhaps, see you then...

davkean commented 6 years ago

@mne91 Yes, closing the solution and reopen after removing the "Custom Tool" for the language-specific ResX (neutral can still have Custom Tool) in the properties windows. Basically, the legacy project system ignores and avoids showing this error, the new project system shows it. We'll fix it in a future update.

RodrigoFCampos commented 6 years ago

I am using windows 10 / iis / .net core 2.1 / latest vs 2017 and I must say that I have 2 resources files:

Resource.resx
Resource.en-US.resx

And sometimes (literally sometimes, because I can't reproduce this error when I want) I get the following error after a build:

Error Custom tool PublicResXFileCodeGenerator failed to produce an output for input file 'Resources\Resource.en-US.resx' but did not log a specific error.

I personally like the last part of the error "... but did not log a specific error." :) I must say that this is a really strange error, because when I click on the error (in the "Error List" menu), the Resource file "Resource.en-US.resx" opens, then I close it, and I run another build and this time no errors appear.

To sum up, well I have no clue of what is happening :P Am I missing something?

davkean commented 6 years ago

Remove the Custom Tools "PublicResXFileCodeGenerator" from the Resource.en-US.resx, and reload the project. You will not see the error again.

RodrigoFCampos commented 6 years ago

To remove the compiler warning I had to remove the Custom Tools "PublicResXFileCodeGenerator"(that davkean just point out) by clicking on the Resource file, pressing F4 to bring up the Properties and then removing the entry for Custom Tool.

tolgabalci commented 5 years ago

Resolved the issue by changing PublicResXFileCodeGenerator to ResXFileCodeGenerator on all language specific resource files. I left the Resource.resx using the PublicResXFileCodeGenerator because that's how other projects consume my Resource library.

brunk01 commented 4 years ago

This helped me if anyone is looking for a quick and dirty fix. https://marketplace.visualstudio.com/items?itemName=DonAirey.ResourceGenerator

JohnyWS commented 4 years ago

@tolgabalci but won't you still get an error when clicking the "Run Custom Tool" option for the files? We removed the designer files completely from the culture specific resources, plus removed the custom tool on the resx, so only the neutral language resx files had the tooling to create designer files.

macux commented 4 years ago

Would be really good if this error could be removed, it just sent me on a wild goose chase whilst trying to localize data annotations in a dotnet core app (which itself is confusing enough).

RoryMcCrossan commented 3 years ago

Still having this issue in VS2019. The RESX editor as a whole is dreadful and badly needs updating.

Latency commented 3 years ago

I am having the same issue with VS2019 v16.7.3 Problem still isn't resolved.

I agree with Rory... this should be compatable.

davkean commented 3 years ago

@Latency ResX isn't deprecated. Did the workaround not work for you?

kiddailey commented 3 years ago

Just wanted to add a note that when this issue occurs in a Xamarin project (VS2019/Win), it appears to disrupt the ability to deploy to a device. The fix for me in these instances is that I have to disconnect from the paired mac and reconnect. It doesn't seem to stop deployment to the simulator though. The workaround does resolve it for me.

For what it's worth, I always have a culture-neutral resource file in my projects (it's typically the first one I add) and I still experience the issue, so it's not limited to projects that don't already have one.

danieldefreitasleite commented 3 years ago

Just set the Access Modifer to No code generation (in fact only the neutral/main resource file will genate the code needed) as showed here: https://dev.to/krusty93/xamarin-android-and-ios-resx-localization-with-mvvmcross-n02.

This way the error should be gone...

kYasinAblay commented 3 years ago

i still doesnt work my project :(

Didier-Solheid commented 3 years ago

Same for me. A nightmare ...

AraHaan commented 3 years ago

I have have just got bitten by this when I have the csproj file itself have the following contents:

<Project Sdk="Microsoft.NET.Sdk" />

While Directory.Build.props contains all of the PropertyGroup Items that should be set for the project, Directory.Build.targets for the ItemGroup entries, and Directory.Packages.props for all ProjectReferences and PackageReferences.

Placing the EmbeddedResource element on an neutral resx file and having it set to ResXFileCodeGenerator on the generator ends up with the resources not getting generated EVER...

I expected it to work even when placed in Directory.Build.targets.

maxkatz6 commented 2 years ago

It's 2021, shouldn't ResXFileCodeGenerator be replaced with new source generator?

AraHaan commented 2 years ago

I found the source generator myself and you can find how I added a reference to it manually in https://github.com/Elskom/Sdk/

However I would love for the Microsoft.NET.Sdk to include that generator by default so then whenever one tries to make a new resx file it won't go about using ResXFileCodeGenerator (and possibly remove ResXFileCodeGenerator at the same time too). But I think that is part of the templates that would need to be updated then as well too.

XtremeOwnageDotCom commented 2 years ago

Well.....

Issues for this problem were originally opened in 2017.

Its now close to Q2 2022, and this is still an issue on the latest .net 6.0 release.

https://github.com/dotnet/project-system/issues/1409 https://github.com/dotnet/project-system/issues/2934 https://github.com/dotnet/project-system/issues/2912 https://github.com/dotnet/project-system/issues/1553 https://social.msdn.microsoft.com/Forums/en-US/25bdfc17-a2b3-4abd-a41f-2414b6ef99ba/custom-tool-resxfilecodegenerator-failed-to-produce-an-output-for-input-file?forum=xamarinforms https://developercommunity.visualstudio.com/t/custom-tool-resxfilecodegenerator-failed-to-produc/854809

I am using updated versions of everything, and the work-arounds are not sufficient.

Now, there are previous tickets, where this is a confirmed issue.

This issue, appears to be extremely easy to replace.

Create a new brand-new empty project. Add Resources.en-us.resx. Boom. You have the error.

@davkean since you have been playing ping-pong with this particular issue for the last 5 years, what does it take for us to get some headway on it?

guiggsrm commented 2 years ago

To solve this problem you have to modify the csproj file. An inconsistence when you copy creates the dependency, but a line to refer the design file is missing.

  <ItemGroup>
    <Compile Update="Properties\Resources.Designer.cs">
      <DesignTime>True</DesignTime>
      <AutoGen>True</AutoGen>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
    <Compile Update="Properties\Resources.en-US.Designer.cs">
      <DesignTime>True</DesignTime>
      <AutoGen>True</AutoGen>
    </Compile>
  </ItemGroup>

Look the DependentUpon tag. You have to create a line equals de design file and close the VS. After that everything works fine;

  <ItemGroup>
    <Compile Update="Properties\Resources.Designer.cs">
      <DesignTime>True</DesignTime>
      <AutoGen>True</AutoGen>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
    <Compile Update="Properties\Resources.en-US.Designer.cs">
      <DesignTime>True</DesignTime>
      <AutoGen>True</AutoGen>
      <DependentUpon>Resources.en-US.resx</DependentUpon>
    </Compile>
  </ItemGroup>
TheCollegedude commented 1 year ago

To solve this problem you have to modify the csproj file. An inconsistence when you copy creates the dependency, but a line to refer the design file is missing.

No, does not work for me.

ocallesp commented 1 year ago

@ocallesp to check if it still reproes

ocallesp commented 1 year ago

This doesn't repro is VS 2022 Main

AraHaan commented 1 year ago

I think the proper way to do this (looking at the runtime repo) is to rig up arcade’s xliff tasks and basically have a single universal resx files but have the language specific copies be *.xlf files.

Nix1983 commented 1 year ago

I get the same error. The problem is the "/" in the value for example "de/counter". How can i made "/" as value?

zorgoz commented 3 months ago

I have VS Version 17.10.0 Preview 2.0, and this is still an issue!

XtremeOwnageDotCom commented 3 months ago

Well.....

Issues for this problem were originally opened in 2017.

Its now close to Q2 2022, and this is still an issue on the latest .net 6.0 release.

1409 #2934 #2912 #1553 https://social.msdn.microsoft.com/Forums/en-US/25bdfc17-a2b3-4abd-a41f-2414b6ef99ba/custom-tool-resxfilecodegenerator-failed-to-produce-an-output-for-input-file?forum=xamarinforms https://developercommunity.visualstudio.com/t/custom-tool-resxfilecodegenerator-failed-to-produc/854809

I am using updated versions of everything, and the work-arounds are not sufficient.

Now, there are previous tickets, where this is a confirmed issue.

This issue, appears to be extremely easy to replace.

Create a new brand-new empty project. Add Resources.en-us.resx. Boom. You have the error.

@davkean since you have been playing ping-pong with this particular issue for the last 5 years, what does it take for us to get some headway on it?

Bump. Been another year.

AraHaan commented 3 months ago

What a shame never fixed yet.

augong0301 commented 3 days ago

same issue after my project migrates from .net framework 48 to .net 8 the custom .resx never generate from that on.