Use ResXFileRef from this project

[bgrainger]

Fixes #5

Detect the fully-qualified type name of the WinForms ResXFileRef type and substitute the one from this project instead.

[farlee2121]

Overall, I see the issue and I think I understand the solution.
My main concern is the broken compatibility with Visual Studio tooling.

I'm not quite sure how else we solve it though, seeing as we can't reference winforms from net standard...

[bgrainger]

My main concern is the broken compatibility with Visual Studio tooling.

Can you explain what you mean here? I wanted this change to enable this library to be able to read a resx file (that was generated by Visual Studio) without requiring all the WinForms dependencies. (That is, to load the resx XML without requiring any change in the type name that was serialised in the XML.) In my testing, enumerating resources from a .NET Framework app produced the exact same key/value pairs as this library with the PR, so it seemed 100% compatible.

I notice that the tests are broken on non-Windows; I'm not sure why that is but can take a look.

[farlee2121]

Your change fixes the library's ability to read Resx files with file references.
But if we then write back to that file, visual studio can't edit that file with it's visual Resx editor anymore.

The second image is using the file produced from this file roundtrip test. I adapted this from your test to make sure we could read files we write, considering the ResXFileRef namespace is changed when we resolve types.

[Fact]
public void ResxDataNode_ResXFileRef_RoundTrip()
{
    var referencedFileContent = Example.FileRef;
    
    var nodeInfo = new DataNodeInfo
    {
        Name = "Test",
        ReaderPosition = new Point(1, 2),
        TypeName = "System.Resources.ResXFileRef, System.Windows.Forms",
        ValueData = "TestResources/Files/FileRef.xml;System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089;utf-8",
    };
    var dataNode = new ResXDataNode(nodeInfo, null);
    var typeResolver = new AssemblyNamesTypeResolutionService(Array.Empty<AssemblyName>());
    
    string resxPath = @".\nya-test.resx";
    using (ResXResourceWriter writer = new ResXResourceWriter(resxPath))
    {
        writer.AddResource(dataNode);
    }
    using(ResXResourceReader reader = new ResXResourceReader(resxPath))
    {
        var dictionary = new Dictionary<object, object>();
        IDictionaryEnumerator dictionaryEnumerator = reader.GetEnumerator();
        while (dictionaryEnumerator.MoveNext())
        {
            dictionary.Add(dictionaryEnumerator.Key, dictionaryEnumerator.Value);
        }

        Assert.Equal(referencedFileContent, dictionary.GetValueOrDefault(nodeInfo.Name));
    }
}

[farlee2121]

Example.FileRef is essentially just a Resx getter for the Test.xml file you provided, that way we can compare the file contents without copying them to code

[farlee2121]

@bgrainger Are you still interested in collaborating on this?

[bgrainger]

Yes, I am. Are you waiting for me to solve the "saving back to XML" problem?

[farlee2121]

I suppose I was waiting for some kind of feedback.
Solving the "saving back to XML" problem is something I think we should do before releasing.
I happy to collaborate, I just don't want to take over your contribution.

[bgrainger]

Sorry for the radio silence.

I'm still interested in having this problem be solved. If you have a solution in mind and know the way forward to implement it, I'm happy for you to take it from here (and use as much or as little of my code as makes sense).

If you don't have the bandwidth to take it on, I'm happy to look at it more (maybe after American Thanksgiving).

[farlee2121]

Sounds good. I pull requested code for some my comments back to your branch.

[farlee2121]

Whenever you're back from vacation, I think I found a good solution to the write issue. I added it to the PR to your branch.

However, I also noticed that we'll run into issues if anyone overwrites the ITypeResolutionService. I'm not sure how likely that is...

I could use some help kicking the tires and poking holes in the test suite.

[bgrainger]

I incorporated your changes and added a couple of fixes that I needed to get the tests working locally.

[farlee2121]

Weird, I thought I had replaced the test file with a StringWriter

[farlee2121]

Could you move this string to ResXConstants?
It's nice to keep all the magic strings in one place.

Also, I noticed the example Resx I made with the VS editor didn't have this whole string as it's type

<data name="Test" type="System.Resources.ResXFileRef, System.Windows.Forms">
  <value>TestResources\Files\Test.xml;System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089;utf-8</value>
</data>

Perhaps we can match on a StartsWith System.Resources.ResXFileRef, System.Windows.Forms (but still keep the constant in ResXConstants

[farlee2121]

Hmm. This also causes the namespace to change when we write the resx.

1. We should probably make sure we can still read the data after we write the changed namespace
2. This breaks compatibility with visual editors. Not sure what to do about that

[farlee2121]

This TypeName could also lean on the ResXConstants value once moved. Consolidates the special strings a bit.

[farlee2121]

This breaks the test on my computer. We can't really write it to favor a particular platform line ending.

Maybe you could use something like ReplaceLineEndings.
We should be able to update the test project's target framework version if need be.

[farlee2121]

@bgrainger I just pushed out new package versions