Help test next version of MonoDevelop/Xamarin Studio add-in

[kobi7]

A minor bug discovered:
try this:

def completionBug
        d = List<of String>()

when you open the parentheses just after string, you get completions for the String ctor, instead of for the List one.
the compiler however is doing the right thing.

hth, kobi

[nerdzero]

Yeah, I'm not parsing generics correctly yet. I'll fix this. Bug is tracked here: https://github.com/ramon-rocha/MonoDeve ... /issues/60 Thanks for reporting it.

[thriwkin]

This is a little bit confusing:
There are 2 versions, both designated as "Cobra Language Binding version 0.5.1".

A: The "precompiled package", available at
http://mdrepo.ramonrocha.com/
It has the AssemblyVersion 1.0.5104.31694.

B: The version "installable from source", available at
https://github.com/ramon-rocha/MonoDevelop.CobraBinding
On 2014-01-02 it had the AssemblyVersion 1.0.5115.30614.


Both are quite different:
A
- can build a solution with more than one project,
- but does not attempt to do "code completion ...".

B
- shows some "code completion ..." behavior,
- but if you add another project it does not build anymore.


Testing A
------------------------------------

A0 - Install the version A.

A1 - Create a new solution, named "A", with a "Cobra Console Project", named "Main"
(Xamarin Studio: New Solution > Cobra > Console Project > Name: "Main", Solution name: "A")

A2 - Add a "Cobra Library Project", named "Lib".

A3 - in "Main" add a Project Reference to "Lib".
("View Solution > Main > References > Edit References... > Projects")

A4 - Close "Xamarin Studio"!.
(To prevent error CS1703.)

A5 - Reopen "Xamarin Studio", and reopen the solution "A".

A6 - In arbitrary order: change the source in "Lib" or "Main", using "Lib" in "Main", and "Build".
It shows "incremental building".
You can inspect the "Build Output" when you point with the mouse on "Errors" at the bottom of the main window.
Do a "Build All", change "Main" but not "Lib", "Build All":
The "Build Output" for "Lib" shows:
' Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files. '

This is very useful. You can divide a solution in several projects, and if the interdependency is low, the "Build" is much faster than the "Rebuild".



Testing B
------------------------------------
B0 - Install the version B.
(Run the "install.cobra" program, if it works then it will overwrite the previously installed version A.)

B1 - Create a new solution, named "B", with a "Cobra Console Project", named "Main".

B2 - Add a "Cobra Library Project", named "Lib".

B3 - In "Main" add a Project Reference to "Lib".

B4 - Close "Xamarin Studio" !
(To prevent error CS1703.)

B5 - Reopen "Xamarin Studio", and reopen the solution "B".

B6 - Change the source in "Lib", then change the source in "Main".
- It shows some "code completion..." behavior !
- "Build (All|Lib|Main)": error MSB3021
- "Rebuild (All|Lib|Main)": error MSB3021
- "Clean (All|Lib|Main)": warning MSB3061
You cannot build anymore, even if you close and reopen the IDE!



Notes

error MSB3021
- Copying file from "obj\Debug\Lib.dll" to "bin\Debug\Lib.dll".
- C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2868,9):
- - error MSB3021: Unable to copy file "obj\Debug\Lib.dll" to "bin\Debug\Lib.dll".
- - The process cannot access the file 'bin\Debug\Lib.dll' because it is being used by another process.

warning MSB3061
- C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3607,9):
- warning MSB3061: Unable to delete file "D:\Dev\_MD\Xmp\B\Lib\bin\Debug\Lib.dll".
- - Access to the path 'D:\Dev\_MD\Xmp\B\Lib\bin\Debug\Lib.dll' is denied.

error CS1703
- error: (...)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll:
- - error CS1703: An assembly with the same identity
- - - "System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
- - has already been imported. Try removing one of the duplicate references.

... But if you remove "System.Core" you will get (later) this error:
error MSB6001
- (MSBuildExtensionsPath)\Cobra\Cobra.targets(149,3):
- - error MSB6001: Invalid command line switch for "cobra.bat". Value cannot be null.
- - (MSBuildExtensionsPath)\Cobra\Cobra.targets(149,3): error MSB6001: Parameter name: collection


Conditions of the tests:
- Windows XP (Microsoft Windows NT 5.1.2600 Service Pack 3)
- .NET CLR v4.0.30319
- XamarinStudio-4.2.2-2.msi

[nerdzero]

I think I know what the problem with multiple projects is. Are you on Windows?

As for the multiple versions with the same version number, yeah I could see how that is confusing. The precompiled package should be considered the "stable" version and installing from source should be considered the "development" version; but I try pretty hard not to push broken code to GitHub. At this point they actually shouldn't be that different in terms of functionality. I'll bump the version in the GitHub repo to 0.5.2 but I'm in the middle of fixing the bug that kobi found and changeset 3092 broke one of my unit tests so it might be a little bit.

[Charles]

Sorry about 3092 causing problems. If you have questions or suggestions, let me know.

[nerdzero]

No need to apologize. Breaking eggs to make omelettes and whatnot

[thriwkin]

Are you on Windows?

Yes: Windows XP, .NET 4.0.

I forgot to specify this, because I peeked a little bit into the source of the add-in and the compiler ... and then I thought: "This cannot work!" - regardless on which platform (Net/Mono, Win/Linux/Mac).

I think I know what the problem with multiple projects is.

What do you think?

[nerdzero]

On Windows/.NET (the behavior is a little different on Mono but still broken), the issue with being unable to build the Lib.dll assembly and getting access denied error messages is due to the way Cobra reads referenced assemblies. It uses Reflection to read the types available in an assembly. This works well when building from the command line but the issue is that an assembly loaded via Reflection cannot be unloaded from that ApplicationDomain until it terminates. That means that other processes cannot overwrite that DLL which causes issues when building from within an IDE.

In this case, here's the sequence of events that trigger this:

1. You create a console project (project A). You can build it without any problems.

2. You create a library project (project B). You can build it without any problems.

3. You add a reference to project B from project A and then you change a source file in project A (or just open it). This triggers the add-in to "compile" the code for project A behind the scenes to support code completion and here's where some problems start.

Since Project A references project B, the compiler phase that reads referenced libraries executes first. The dll for project B is now locked by the ApplicationDomain for MonoDevelop.exe (the add-in is a library that is invoked by MonoDevelop.exe). The background "compliation" completes and now you have code completion for types defined in Project B when changing code in project A. Now you try to change and build project B. The add-in builds the appropriate command line arguments and then invokes cobra.exe (indirectly via msbuild.exe) to build project B. But, the dll for project B is locked by MonoDevelop.exe because it was loaded via Reflection when we changed a file in project A. Boom! Error message.

So why then does the error seem to persist even when you restart the IDE? When you open a solution, a parse request is made for all files. The add-in ignores these initial parse requests for performance reasons except for files that are already open. MonoDevelop/Xamarin Studio remembers the last files you had open for a solution. So, if you close the IDE with a file for project A open, when you open the solution again, a background compilation for project A is made and locks the dll for project B right away. /sadtrombone. If you close all files before you close MonoDevelop and then first file you open is one from project B, it will compile okay. Less than ideal.

So what can we do? Well, there's another way to use Reflection such that the DLL will be copied to a different location before being loaded, that way the original DLL is not locked. This is called shadow copying: http://msdn.microsoft.com/en-us/library/ms404279(v=vs.100).aspx
It's not as straight forward as it sounds though because passing references of a type from the shadow loaded DLL to a different application domain now locks it in the other app domain as well. Things have to be marshalled using interfaces defined in another assembly to keep everything isolated. It's a fair amount of work to get right. At least it sounds like it. I didn't do much more investigation because I like the next option a bit better.

Another option is to use a different mechanism besides Reflection to read assembly references that doesn't lock the files. Mono.Cecil is an option: https://github.com/jbevain/cecil/wiki/HOWTO I played with it a bit last night and what I can do is replace the ReadLibrariesPhase that would normally be run by the Cobra compiler with a custom phase like I do with the BindImplementationPhase that uses Mono.Cecil to generate the information the compiler will need to resolve types coming from references. I think it will do the trick. It's still a lot of work, but my gut says it's less work than shadow copying.

I wouldn't be opposed to someone helping with this or trying a parallel effort (either in the add-in or the Cobra compiler itself).

P.S. I pushed a first pass at a fix for the bug found by kobi, I bumped the version number of the add-in on GitHub, and I fixed the regression from changeset 3092.

P.P.S. Sorry I typed so much.

[thriwkin]

Sorry I typed so much.

Thanks for typing so much!

I want to think about it, maybe it will take a few days, before I post a reply.

[Charles]

Is reflection-only loading on Windows a potential option to resolve these problems? I think you had trouble with that before, but I don't recall the details, let alone whether the details would have changed for .NET 4 and up.