Weird Compilation Error....

Extended
1

I’ve just attempted to build a MonoGame Windows UAP Release project with MonoGame.Extended and got the following:

C:\Program Files (x86)\MSBuild\Microsoft\.NetNative\x86\ilc\IlcInternals.targets(936,5): error : MCG0037: MCG0037:InvalidCSharpIdentifierName Struct 'MonoGame.Extended.Particles.HslColor' in assembly 'Assembly(Name=MonoGame.Extended, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, Location=C:\Users\********\Documents\Visual Studio 2015\Projects\******\******\obj\x86\Release\ilc\in\MonoGame.Extended.dll)' has a field with name '<H>k__BackingField' that is invalid. This could be because the name is obfuscated or the field is auto-implemented by the compiler. Please make sure the field name follows C# identifier conventions.

It doesn’t happen on a Debug version of the same and it doesn’t happen with the DesktopGL Release project either.

Any ideas/help appreciated…

2

That is a really weird error. I’m surprised I can’t find any information about it on the internet. The only other search result that showed up was this one.

The error appears to be saying that the H property of the HslColor struct doesn’t follow C# identifier conventions. I find that surprising. I guess we could try renaming it to Hue but I’m not sure if that’s really the problem here.

I suspect this is more an issue with Windows UAP or .NetNative projects than MonoGame.Extended. I would like to get to the bottom of it though. It’s a curious one.

3

Because the backing field is generated by the compiler, it can be guaranteed to avoid conflict with a name the developer has used by utilizing characters that are not legal in regular code. That some of those generated names for the backing fields may fall foul of .NET Native’s naming requirements is a bit of an oversight, and one I’m sure they will address soon enough.

For now, you may have to try something different than the new C# 6 getter-only automatic properties. A public const float H; should give the same effect for the immutable field and should eliminate this error.

4

Yes - hopefully they’ll sort it out soon.

Ive gone for readonly float for the H, S and L fields (it affects all three) as they are constructor rather than declaration assigned.

5

That works better. I usually forget about that modifier because I use it so rarely.

6

This seems like the right way to go. I don’t have a Windows UAP project setup to test it with. Can I have a look at your exact code @Andy_E so I can make this change in the develop branch?

Thanks for the explanation @KonajuGames. Very helpful.

7

Hi Dylan, see below…
`

    /// <summary>
    /// Gets the value of the hue channel in degrees.
    /// </summary>
    public readonly float H;

    /// <summary>
    /// Gets the value of the saturation channel.
    /// </summary>
    public readonly float S;

    /// <summary>
    /// Gets the value of the lightness channel.
    /// </summary>
    public readonly float L;

`

8

Thanks @Andy_E. I’ve made this change in the develop branch.