Skip to content

Use dotnet-resgen to compile resx files #743

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
andyleejordan merged 11 commits into from
Mar 28, 2016
Merged

Use dotnet-resgen to compile resx files #743

andyleejordan merged 11 commits into from
Mar 28, 2016

Conversation

@andyleejordan
Copy link
Member

@andyleejordan andyleejordan commented Mar 26, 2016

Improvement

Specifically this enables us to leverage dotnet-resgen to auto-generate the resx files into resources files for the default culture, which are then compiled into the respective assemblies.

@vors Since .resources no longer need to be compiled on Windows and added to windows-build, #732 should be updated to map the .resx files into the superproject as well.

Requires PowerShell/psl-windows-build#10.

Caveat

This requires a change to the C# bindings. The Windows build system takes file.resx and compiles file.resources, but CLI prepends the assembly name, thus compiling SMA.file.resources. So the resource manager in the generated bindings must be adjusted to look for SMA.file instead of file.

Note that C# bindings cannot yet be auto-generated; so if they need to be updated, the above must be changed again. This is still blocked on #395 / dotnet/cli#819. However, the C# bindings need to be updated only if strings are added/removed, not when their content changes.

Localization

@vors I've discovered that given localized resources of the form file.en-US.resx, dotnet-resgen will create a satellite assembly and publish it to en-US/SMA.resources.dll, so #666 will not be a technical problem.

/cc @SteveL-MSFT @BrucePay @dantraMSFT

This change is Reviewable

@andyleejordan
Fix VS Code attach debugging configuration
18ba3f3 
Needs to be `processName`, not `program`. Go figure.
@andyleejordan
Replace SMA's namedResource section with resource
9a52f1e 
Specifically this enables us to leverage `dotnet-resgen` to
auto-generate the `resx` files into `resources` files for the default
culture, which are then compiled into the SMA assembly.

This requires a change to the C# bindings. The Windows build system
takes `file.resx` and compiles `file.resources`, but CLI prepends the
assembly name, thus compiling `SMA.file.resources`. So the resource
manager in the generated bindings must be adjusted to look for
`SMA.file` instead of `file`.

Note that C# bindings cannot yet be auto-generated.

Given localized resources of the form `file.en-US.resx`, `dotnet-resgen`
will create a satellite assembly and publish it to
`en-US/SMA.resources.dll`, so #666 will not be a technical problem.
@andyleejordan
Replace Utility's namedResource section with resource
3979d4c
@andyleejordan
Replace Management's namedResource section with resource
76fd8bd
@andyleejordan
Replace Security's namedResource section with resource
b363fc9
@andyleejordan
Replace ConsoleHost's namedResource section with resource
af92960
@andyleejordan
Replace Eventing's namedResource section with resource
3d8a3b9
@andyleejordan
Bump windows-build submodule with resources fixes
aedaf53
@andyleejordan
Add System.IO.MemoryMappedFiles dependency
6433650 
This is a runtime dependency that causes an internal exception to be
thrown and caught when not available.
@andyleejordan
Set default culture to en-US
2f29f43 
So that the resource manager doesn't try to load a non-existent
satellite assembly (and thus throw).

The culture `en-US` is the default `CurrentCulture` on all platforms I
tested, specifically not `en`.

Note that there is a problem with the FullCLR build where some other
assembly is still attempting to reference `Logging.resources` instead of
`System.Management.Automation.Logging.resources`.
@andyleejordan
Copy link
Member Author

andyleejordan commented Mar 27, 2016

@vors I'm going to need some help making this work with the FullCLR build. There is a problem with the FullCLR build where some other assembly is still attempting to reference Logging.resources instead of
System.Management.Automation.Logging.resources, but I can't figure out which assembly is doing so. This is causing the build to fail because the host fails to initialize.

@vors
Copy link
Collaborator

vors commented Mar 27, 2016

ok, lets take a look on Tuesday

@andyleejordan
Copy link
Member Author

andyleejordan commented Mar 28, 2016

Here it is:

C:\Users\anschwa\src\PowerShell [andschwa/wip-culture ≡ +0 ~2 -0 !]> Start-DevPSGitHub -binDir $pwd\binFull -NoNewWindow
 -ArgumentList '-command', '[System.Globalization.CultureInfo]::CurrentUICulture'
Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "Logging.resources
" was correctly embedded or linked into assembly "System.Management.Automation" at compile time, or that all the satelli
te assemblies required are loadable and fully signed.
Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "Logging.resources
" was correctly embedded or linked into assembly "System.Management.Automation" at compile time, or that all the satelli
te assemblies required are loadable and fully signed.
Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "Logging.resources
" was correctly embedded or linked into assembly "System.Management.Automation" at compile time, or that all the satelli
te assemblies required are loadable and fully signed.
Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "Logging.resources
" was correctly embedded or linked into assembly "System.Management.Automation" at compile time, or that all the satelli
te assemblies required are loadable and fully signed.
Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "Logging.resources
" was correctly embedded or linked into assembly "System.Management.Automation" at compile time, or that all the satelli
te assemblies required are loadable and fully signed.
Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "Logging.resources
" was correctly embedded or linked into assembly "System.Management.Automation" at compile time, or that all the satelli
te assemblies required are loadable and fully signed.
The shell cannot be started. A failure occurred during initialization:
Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "Logging.resources
" was correctly embedded or linked into assembly "System.Management.Automation" at compile time, or that all the satelli
te assemblies required are loadable and fully signed.

This error would make sense if SMA's resource C# bindings had not been fixed. However, as evidenced from Core and Linux working, SMA indeed is fine.

So what, outside of our code, would be using SMA's resource bindings directly?

@andyleejordan
Copy link
Member Author

andyleejordan commented Mar 28, 2016

Found it. The EventLog code uses a ResourceManager directly and manually tried to load the resources file (rather than through the C# bindings), so a use there had to be updated too.

This now requires PowerShell/psl-monad#42 too.

@andyleejordan andyleejordan merged commit 7057c4b into master Mar 28, 2016
@andyleejordan andyleejordan deleted the andschwa/cli-resources branch March 28, 2016 18:27
This was referenced Mar 28, 2016
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@andyleejordan @vors