GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
0.7.4 version provides PublicResXFileScriptGenerator tool which allows to generate resource classes as public.
It seems that custom tools are eliminated in the new approach of Script# NuGet based distribution (and probably this makes sense).
But the need to generate public resources still alive :)
What about using resx files naming convention to tell ResXCodeBuilder what class access modifier to use?
MsgRes.resx -> internal access
MsgRes.internal.resx -> internal access
SharedRes.public.resx -> public access
This will allow to avoid any custom tools registration and distribution.
Yes, I generally agree - it is still interesting.
When I made the change, I was hopeful of finding a way to save/read some metadata inside the resx file itself ... however that doesn't lend itself well to the current IDE experience ... would require opening the resx file with xml editor rather than default. Then I was thinking of maybe a magic name/value pair that could be used for these sort of purposes. Eventually I didn't do it as I thought in most cases resources are internal, and not part of the public API of a library, i.e. there would be other public APIs that might use/return those resources.
The reason I didn't go for file name based convention was that there is an existing model for providing locale-specific variants that relies on file names... eg. MsgRes.fr.resx... which means the logic to separate neutral resources from locale-specific ones would also have to be modified to special case "public".
Any thoughts on the magic pair approach? For example, have a value named "AccessModifier" whose value can be Public or Internal?
If you'd like, you could avoid waiting on this, and go ahead and take a stab at this and create a pull request. The change should be pretty straightforward. The generator is in https://github.com/nikhilk/scriptsharp/blob/master/src/Core/Build/Generators/ResXCodeBuilder.cs.
Simply set the Custom Tool property of a resx file to "PublicResxScriptGenerator" - the msbuild resource code generator will pick up this property and switch the generated class to use public as access modifier instead of the default internal one.
The fix is committed, so you can build if you'd like support for the scenario immediately. It will be in the next release.
Thanks a lot!
You didn't give me any chance to try :)
NP... will let you tackle the next thing... :-)
I was looking at a resx in a project and had an idea flash by to continue to use the generator name that simply didn't map to a generator, and was curious to see whether it could work or not. Pretty much ended up doing the work to try answer that question.