Ticket #125 (closed defect: fixed)

Opened 12 years ago

Last modified 12 years ago

compilation failure with 3rd party libs

Reported by: gauthier Owned by: Chuck
Priority: major Milestone: Cobra 0.9
Component: Cobra Compiler Version: 0.8.0
Keywords: Cc:


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

using nunit & castle monorail

Change History

Changed 12 years ago by Chuck

  • owner set to Chuck
  • status changed from new to accepted

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

Changed 12 years ago by 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;
	class SomeTestFixture : BaseViewComponentTest {
		void Setup() {
		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=, 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.

Changed 12 years ago by 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)

Changed 12 years ago by 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.

Changed 12 years ago by 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.

Changed 12 years ago by 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.

Changed 12 years ago by Chuck

  • status changed from accepted to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.