Topic: Conflict between the "GUI" namespace and the "GUI" type

[Monsieur OUXX]

In the Editor's source, there are two things named "GUI" :
- the type: AGS.Types.GUI
- the namespace: AGS.Editor.GUI

I've tried building the solution with Visual Studio 2010 Ultimate, and it fails to resolve the conflict: It says "AGS.Editor.GUI is a namespace but is used as a type", for example when compiling GUIEditor.cs
This is worked around by explicitly replacing "GUI" with "AGS.Types.GUI" in the source. For example : "private GUI _gui = null;" becomes "private AGS.Types.GUI _gui = null;"

Am I missing something? Is it the newest VS being stricter, or is it a setting to change?

[monkey_05_06]

I didn't think you could use namespaces that way.

Anyway, it builds fine under VS2008 Express.

[Monsieur OUXX]

I didn't think you could use namespaces that way.

I didn't understand what you meant.

Anyway, it builds fine under VS2008 Express.

So that means it's VS2010 that has become stricter (assuming it hasn't become more stupid in its conflict resolution).

[Snarky]

It usually depends on the import using (sorry, was thinking Java) statements at the top of the file. If you import the whole namespace it can cause a conflict, while if you import just the classes you need, it'll resolve fine. Highly automated insertion of import using statements is available in VS, so is it possible that you've changed the file in some subtle way?

[Calin Leafshade]

I believe conflict resolution in C# is not always explicit. Sometime conflicts will be resolved based upon constructor parameters so it depends how you are instantiating the objects.

However, in 99% of cases its simply due to the using statements at the top (not 'import', what is this ? python?).

Also, since conflict resolution is done by the compiler, not the ide (even by intellisense) it shouldnt matter which ide you use, only which compiler, which is dependant on the version of .NET you are targeting, which should be 2.0 for the AGS editor.

[Monsieur OUXX]

Also, since conflict resolution is done by the compiler, not the ide (even by intellisense) it shouldnt matter which ide you use, only which compiler, which is dependant on the version of .NET you are targeting, which should be 2.0 for the AGS editor.

Yes, but imagine the following scenario :
- VS 2010 (and compiler)  introduces new warning levels or conflict resolution rules
- Those rules didn't exist in Vs 2008
- When I import the AGS solution in VS 2010, it sets those new rules to "enabled" by default
- Hence the code that was correctly compiling in 2008 doesn't compile anymore in 2010.

I imagine this scenario because I almost certain that the conflict existed immediately after import, even before I introduced any custom code.