compilation failure with 3rd party libs

[gauthier]

compiling with "cobra main.cobra -v:3 -exception-report -reveal-internal-exceptions" gives AssertException?

using nunit & castle monorail

[Chuck]

See  http://cobra-language.com/forums/viewtopic.php?f=4&t=274

[Chuck]

Progress made in changeset:1891 but still more to do.

[Chuck]

The current problem is that when Cobra sees "Test" it binds it to the "Test" namespace in Castle.MonoRail.Framework.Test. I wanted to see how C# would handle this, so I translated the code to C#, which was easy:

namespace Here {
	using NUnit.Framework;
	using Castle.MonoRail.Framework;
	using Castle.MonoRail.Framework.Test;
	using Castle.MonoRail.TestSupport;
	[TestFixture]
	class SomeTestFixture : BaseViewComponentTest {
		[SetUp]
		void Setup() {
		}
		[Test]
		void CompileFail() {
		}
	}
	class Program {
		static void Main() {
		}
	}
}

But compilation proved difficult. From a VS 2005 command prompt:

>csc -r:nunit.framework x-ticket-125.cs
error CS0006: Metadata file 'nunit.framework' could not be found

But it's there:

>gacutil -l nunit.framework
The Global Assembly Cache contains the following assemblies:
  nunit.framework, Version=2.4.2.0, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77

I tried with and without the .dll extension and with mixed case and all lower case. So I'm not sure how to proceed with the C#.

Another idea is to recreate this problem with freshly created DLLs like we've done in other cases. The idea is to show an example where C# code compiles fine, but the equivalent Cobra does not due to a bug in binding symbols.

[gauthier]

You are right about the namespace c# error, sorry for not remembering this case, but cobra version with TestAttribute? doesn't compile :(

note that the c# with TestAttribute? compiles

with this ticket, I can't currently unit test my code base with cobra and need to workaround

from parsing perspective, if an identifier (as attribute) with single part (is just the class name) then cobra compiler shouldn't look for that particular case of absolute naming (which can occur if there is a multiple parts identifier)

[Chuck]

I managed to create a couple of small DLLs and then use them from C#, but fail to use them from Cobra. The reason has to do with how the two compilers treat "use/using" and namespaces. It does not appear to be a case issue, but a precedence issue.

Now that I have an isolated, broken case, I should be able to fix soon.

[Chuck]

Okay, I discovered that C#'s using does not import subnamespaces whereas VB and Cobra do. You can fix your code in Cobra by qualifying "has Test" as "has NUnit.Framework.Test" -- this works on my system. This was not previously possibly because of a bug regarding qualified attributes, but that has been fixed.

I will be doing some more research on Cobra's treatment of namespaces and use directives vs. C# and VB. But in the meantime you can proceed give the other bugfix and the qualification.

Let me know if you have further problems.

[Chuck]

Well VB is even more interesting than C# and Cobra! When confronted with multiple Imports:

Imports A
Imports B

where one provides a "Foo" namespace and one provides a "Foo" class, VB neither complains nor requires qualification, but instead favors the class over the namespace. To get to the namespace, you must qualify it via its parent namespace.

But note that if there is only one "Foo" and that is a namespace, you can use it directly without qualifying it via its parent namespace (unlike C# which will does not give visibility to subnamespaces).

Also, this behavior is independent of the order of the Imports.

I believe that if Cobra had these semantics, then "has Test" would have worked.

So what if there are two "Foo" and both are classes? Then using Foo in VB gives:

'Foo' is ambiguous, imported from the namespaces or types 'B, A'.

• Cobra should definitely detect ambiguity.
• Should it give precedence of a single class over a namespace as VB does?

I'll need to sleep on this.

Btw, don't let this long message confuse you into halting your progress. You can proceed by using full qualification.

[Chuck]

Improvements were made around namespaces on 2008-01-13 and described in the forum post  Namespace clarifications.