ccrewrite fails to read assembly that has non-escaped comma in nested type names

[SergeyTeplyakov]

Related to the #186.

If old version of ccrewrite could generate type names that with non-espcaped comman inside when working with Roslyn-generated code.

It means, that instead of SomeGeneric+Nested<Int32\,String> it can generate SomeGeneric+Nested<Int32,String>. But actually both cases are correct and metadata reader should deal with both of them smoothly.

[tom-englert]

@SergeyTeplyakov please reopen this issue.

With this fix we get crashes in ccrewrite for generic types:

the class with it's attribute looks something like this:

[Export(typeof(IEntityToDtoMapping<TestOrder, Modules.TestOrder.ServerAccess.TestOrder, IPersistenceContext>))]
private class Mapping : EntityToDtoMapping<TestOrder, Modules.TestOrder.ServerAccess.TestOrder, IPersistenceContext>
{

which will generate a type name like this:

AVL.Core.EF6.IEntityToDtoMapping`3[QualityManager.TestOrders.Server.Persistence.TestOrder,[QualityManager.Modules.TestOrder.ServerAccess.TestOrder, QualityManager.Modules.TestOrder, Version=2.0.499.0, Culture=neutral, PublicKeyToken=null],QualityManager.TestOrders.Server.Persistence.IPersistenceContext], AVL.Core.EF6, Version=2.0.2963.0, Culture=neutral, PublicKeyToken=c9dcc53cc7f12ccb

and an error like this:

Could not resolve type reference: [mscorlib]QualityManager.TestOrders.Server.Persistence.TestOrder,.
Could not resolve type reference: [mscorlib]QualityManager.Modules.TestOrder.ServerAccess.TestOrder.
Could not resolve type reference: [mscorlib]QualityManager.Modules.TestOrder.
Could not resolve type reference: [mscorlib]Version=2.0.499.0.
Could not resolve type reference: [mscorlib].Culture=neutral.
Could not resolve type reference: [mscorlib].PublicKeyToken=null.

[SergeyTeplyakov]

Could you provide a small repo solution that I can try? I can revert the change if solution would be complicated...

[tom-englert]

I have a fix already in #445, just looking how to add a test for this scenario. Did you have a test for the original issue?

[SergeyTeplyakov]

Yep, I've faced an issue but that was not a critical and more artificial case. I'll role this change back.

[SergeyTeplyakov]

It seems that you fix it in your fork. If you'll create PR I'll merge it.

[tom-englert]

#445 is a pull request 😏

[SergeyTeplyakov]

Oops! Thought it is an old one. Will merge once appveyor will be finished.

[tom-englert]

After adding a test I could not find the scenario described here - instead with the code introduced in #341 it was not able to read it at all, so I have reverted the complete fix in PR #446