ccrewrite produces an incorrect type name in IteratorStateMachineAttribute with some generic types

[fedotovalex]

This is related to #47. Now that parsing of escaped type names in attributes had been fixed, ccrewrite fails to escape it back when producing the rewritten assembly. It seems to have no runtime effect, but it causes problems if this assembly is referenced by another assembly that is also rewritten. ccrewrite attempts to parse the referenced assembly and fails due to an incorrect type name encoded in the attribute.

Pull request with a fix will follow as soon as I figure out how to add a unit test for it.

[SergeyTeplyakov]

Could you provide a concrete example? Then I'll try to repro this in tests and will put some notes here how to add tests for such cases.

[fedotovalex]

The way I discovered it is by having two projects, both of which have ccrewrite enabled.

Library.cs => Library.dll

using System;
using System.Collections;
using System.Collections.Generic;

namespace Library
{
    public class Utility : IEnumerable<Tuple<string, string>>
    {
        IEnumerator<Tuple<string, string>> IEnumerable<Tuple<string, string>>.GetEnumerator()
        {
            yield break;
        }

        IEnumerator IEnumerable.GetEnumerator()
        {
            yield break;
        }
    }
}

Application.cs => Application.exe

namespace Application
{
    class Program
    {
        static void Main(string[] args)
        {
            new Library.Utility();
        }
    }
}

When compiling the Application project, you get

2>  Reading assembly 'Library' from 'C:\Projects\Test\Library\bin\Release\Library.dll' resulted in errors.
2>      Illegal characters in path.
2>ccrewrite : error : Rewrite aborted due to metadata errors. Check output window

And the reason for this is the iterator type name which was not properly escaped: <System-Collections-Generic-IEnumerable<System-Tuple<System-String,System-String>>-GetEnumerator>d__0. Parsing it stops at the comma assuming that everything that follows is the assembly specification, hence the "Illegal characters in path" error when it tries to look up that assembly.

For a unit test, I was thinking it may be easier just to compile the code in Library and parse it back somehow. This doesn't follow the typical build-rewrite-run approach in Foxtrot unit tests, that's why I needed a bit more time figuring out how to best structure it.

[SergeyTeplyakov]

Thanks a lot! I'll try to add the test now.

[SergeyTeplyakov]

Faced similar issue today. Thanks for fixing it!