crossnet Wiki & Documentation Rss Feed

New Comment on "started"

mjaggard — Thu, 11 Nov 2010 15:55:03 GMT

Reflector crashes each time I run it with /crossnet :-(

Updated Wiki: started

OlivierNallet — Wed, 12 May 2010 01:38:44 GMT

How to get started?

Here are all the steps to get started. Depending of your knowledge of Microsoft Visual Studio, it can take 15 minutes to 1 hour.

Create a temporary folder (named C:\TempFolder here) where you will setup everything.
1. Download latest version of Reflector and unzip it - http://www.red-gate.com/products/reflector/
2. Download CrossNet sources - http://crossnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=7414
3. Download CrossNetSystem sources - http://crossnetsystem.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=7856
Unzip all and remove read only attributes for all the files (except if you are using a revision control system).
Open Microsoft Visual Studio 2005. If you are using 2008, it will upgrade the projects automatically for you.
1. Create an empty solution.
2. Move the parent folder of each projects in the same folder as the solution file. (i.e. we skip the package name and version). Although you can have put the projects where you want, it will reduce the setup later.
3. You should end up with something like that:
  1. C:\TempFolder\CrossNet.sln
  2. And for each project (like for CrossNetRuntime):
  3. C:\TempFolder\CrossNetRuntime\CrossNetRuntime.vcproj
  4. C:\TempFolder\CrossNetRuntime\includes\...
  5. C:\TempFolder\CrossNetRuntime\sources\...
  6. So each project file should be one level below the solution file.
Add every projects to the solution. You should have 7 projects in the solution:
1. CplusplusBenchmark
2. CrossNetBenchmark
3. CrossNetParser
4. CrossNetRuntime
5. CrossNetSystem
6. CSharpBenchmark
7. Reflector.CrossNet
Duplicate the file Reflector.exe and rename it to Reflector.dll. You will need to do that everytime you update the version of Reflector.
Open the projects "CrossNetParser" and "Reflector.CrossNet" and update the references to the Reflector.dll that you just created.
Now we need to fix up the runtime references and the BCL references to CrossNetBenchmark, we are going to use CrossNetSystem for that. Open CrossNetBenchmark properties, go into the Configuration properties -> Linker -> Inputs
1. In additional dependencies, type: ..\$(ConfigurationName)\CrossNetRuntime.lib ..\$(ConfigurationName)\CrossNetSystem.lib
2. Build CrossNetBenchmark and there should be no compile / link error.
Now compile CrossNetParser and you should have 4 compile errors. This is expected. Since October 2007, Reflector API changed for the using keyword. For the moment, replace .Variable by .Expression. I'll send you a real fix if you are using "using" :) Sorry about that.
At that point you should be able to compile the whole solution without any error.
Copy Reflector.CrossNet.dll and CrossNet.dll where you have Reflector.exe. If you built the whole solution, the two dlls should be in the bin folder of Reflector.CrossNet.

Now that everything is configured correctly we can start to have fun.

Compile CSharpBenchmark. If you want to run it and see what the benchmark does:
1. Rename the method Test() in the class CSharpBenchmark._Benchmark.Benchmark to Main()
2. Make the library a console application.
3. Run the C# Benchmark.
Revert these changes for the C++ conversion.
Once compiled, go in the folder Reflector.CrossNet and modify example.xml like this:
1. Change <OutputFolder>YourOutputPath</OutputFolder> to <OutputFolder>C:\TempFolder\CrossNetBenchmark\</OutputFolder>
2. Change <AssemblyToParse>FirstPath\FirstAssembly.dll</AssemblyToParse> to <AssemblyToParse>C:\TempFolder\CSharpBenchmark\bin\Debug\CSharpBenchmark.dll</AssemblyToParse>
3. Remove <AssemblyToParse>SecondPath\SecondAssembly.dll</AssemblyToParse>
4. Make sure that the paths are correct.
5. You will need to change the xml file only when adding new assemblies (to parse or to reference)
Run Reflector.exe, select .NET 2.0 runtime version (it should not matter but never know).
1. Go in View -> AddIns, and add Reflector.CrossNet to the list of add-ins.
2. If you regularly use Reflector make sure that the optimization mode is set to .NET 2.0 (not 3.0+).
3. Close Reflector.exe.
4. Open the command prompt (run cmd.exe) and go in the folder where Reflector.exe is located (and the 2 other dlls).
5. Type: Reflector.exe /crossnet:C:\TempFolder\Reflector.CrossNet\Example.xml
6. This will show Reflector UI for few seconds and should close it after a short beep.
7. If you go in CrossNetBenchmark folder you should see the C++ sources updated.
Go back to Visual Studio, compile again CrossNetBenchmark, it should compile and link correctly (there may be some link warnings about missing pdbs).
1. You can now run the benchmark (C# code translated in C++).
List of things that you should consider at some point:
1. Make step 4 a post-build step to the step 1. (using a batch file).
2. Switch the C++ code to release to have real performance.
3. Tweak the compile flags to optimize more. Set the dependencies correctly in the solution.
4. Modify the C# benchmark code or reference your own assembly instead.
5. Remember to augment CrossNetSystem if you are using more CLR classes (and share with the community).
6. etc...

Enjoy and have fun!

Updated Wiki: started

OlivierNallet — Tue, 21 Apr 2009 04:25:02 GMT

How to get started?

Here are all the steps to get started. Depending of your knowledge of Microsoft Visual Studio, it can take 15 minutes to 1 hour.

Create a temporary folder (named C:\TempFolder here) where you will setup everything.
1. Download latest version of Reflector and unzip it - http://www.red-gate.com/products/reflector/
2. Download CrossNet sources - http://crossnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=7414
3. Download CrossNetSystem sources - http://crossnetsystem.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=7856
Unzip all and remove read only attributes for all the files (except if you are using a revision control system).
Open Microsoft Visual Studio 2005. If you are using 2008, it will upgrade the projects automatically for you.
1. Create an empty solution.
2. Move the parent folder of each projects in the same folder as the solution file. (i.e. we skip the package name and version). Although you can have put the projects where you want, it will reduce the setup later.
3. You should end up with something like that:
  1. C:\TempFolder\CrossNet.sln
  2. And for each project (like for CrossNetRuntime):
  3. C:\TempFolder\CrossNetRuntime\CrossNetRuntime.vcproj
  4. C:\TempFolder\CrossNetRuntime\includes\...
  5. C:\TempFolder\CrossNetRuntime\sources\...
  6. So each project file should be one level below the solution file.
Add every projects to the solution. You should have 7 projects in the solution:
1. CplusplusBenchmark
2. CrossNetBenchmark
3. CrossNetParser
4. CrossNetRuntime
5. CrossNetSystem
6. CSharpBenchmark
7. Reflector.CrossNet
Duplicate the file Reflector.exe and rename it to Reflector.dll. You will need to do that everytime you update the version of Reflector.
Open the projects "CrossNetParser" and "Reflector.CrossNet" and update the references to the Reflector.dll that you just created.
Now we need to fix up the runtime references and the BCL references to CrossNetBenchmark, we are going to use CrossNetSystem for that. Open CrossNetBenchmark properties, go into the Configuration properties -> Linker -> Inputs
1. In additional dependencies, type: ..\$(ConfigurationName)\CrossNetRuntime.lib ..\$(ConfigurationName)\CrossNetSystem.lib
2. Build CrossNetBenchmark and there should be no compile / link error.
Now compile CrossNetParser and you should have 4 compile errors. This is expected. Since October 2007, Reflector API changed for the using keyword. For the moment, replace .Variable by .Expression. I'll send you a real fix if you are using "using" :) Sorry about that.
At that point you should be able to compile the whole solution without any error.
Copy Reflector.CrossNet.dll and CrossNet.dll where you have Reflector.exe. If you built the whole solution, the two dlls should be in the bin folder of Reflector.CrossNet.

Now that everything is configured correctly we can start to have fun.

Compile CSharpBenchmark. If you want to run it and see what the benchmark does:
1. Rename the method Test() in the class CSharpBenchmark._Benchmark.Benchmark to Main()
2. Make the library a console application.
3. Run the C# Benchmark.
Revert these changes for the C++ conversion.
Once compiled, go in the folder Reflector.CrossNet and modify example.xml like this:
1. Change <OutputFolder>YourOutputPath</OutputFolder> to <OutputFolder>C:\TempFolder\CrossNetBenchmark\</OutputFolder>
2. Change <AssemblyToParse>FirstPath\FirstAssembly.dll</AssemblyToParse> to <AssemblyToParse>C:\TempFolder\CSharpBenchmark\bin\Debug\CSharpBenchmark.dll</AssemblyToParse>
3. Remove <AssemblyToParse>SecondPath\SecondAssembly.dll</AssemblyToParse>
4. Make sure that the paths are correct.
5. You will need to change the xml file only when adding new assemblies (to parse or to reference)
Run Reflector.exe, select .NET 2.0 runtime version (it should not matter but never know).
1. Go in View -> AddIns, and add Reflector.CrossNet to the list of add-ins.
2. If you regularly use Reflector make sure that the optimization mode is set to .NET 2.0 (not 3.0).
3. Close Reflector.exe.
4. Open the command prompt (run cmd.exe) and go in the folder where Reflector.exe is located (and the 2 other dlls).
5. Type: Reflector.exe /select:Reflector.CrossNet /crossnet:C:\TempFolder\Reflector.CrossNet\Example.xml
6. This will show Reflector UI for few seconds and should close it after a short beep.
7. If you go in CrossNetBenchmark folder you should see the C++ sources updated.
Go back to Visual Studio, compile again CrossNetBenchmark, it should compile and link correctly (there may be some link warnings about missing pdbs).
1. You can now run the benchmark (C# code translated in C++).
List of things that you should consider at some point:
1. Make step 4 a post-build step to the step 1. (using a batch file).
2. Switch the C++ code to release to have real performance.
3. Tweak the compile flags to optimize more. Set the dependencies correctly in the solution.
4. Modify the C# benchmark code or reference your own assembly instead.
5. Remember to augment CrossNetSystem if you are using more CLR classes (and share with the community).
6. etc...

Enjoy and have fun!

Updated Wiki: started

OlivierNallet — Tue, 21 Apr 2009 04:09:01 GMT

How to get started?

Here are all the steps to get started. Depending of your knowledge of Microsoft Visual Studio, it can take 15 minutes to 1 hour.

Create a temporary folder (named C:\TempFolder here) where you will setup everything.
1. Download latest version of Reflector and unzip it - http://www.red-gate.com/products/reflector/
2. Download CrossNet sources - http://crossnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=7414
3. Download CrossNetSystem sources - http://crossnetsystem.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=7856
Unzip all and remove read only attributes for all the files (except if you are using a revision control system).
Open Microsoft Visual Studio 2005. If you are using 2008, it will upgrade the projects automatically for you.
1. Create an empty solution.
2. Move the parent folder of each projects in the same folder as the solution file. (i.e. we skip the package name and version). Although you can have put the projects where you want, it will reduce the setup later.
3. You should end up with something like that:
  1. C:\TempFolder\CrossNet.sln
  2. And for each project (like for CrossNetRuntime):
  3. C:\TempFolder\CrossNetRuntime\CrossNetRuntime.vcproj
  4. C:\TempFolder\CrossNetRuntime\includes\...
  5. C:\TempFolder\CrossNetRuntime\sources\...
  6. So each project file should be one level below the solution file.
Add every projects to the solution. You should have 7 projects in the solution:
1. CplusplusBenchmark
2. CrossNetBenchmark
3. CrossNetParser
4. CrossNetRuntime
5. CrossNetSystem
6. CSharpBenchmark
7. Reflector.CrossNet
Duplicate the file Reflector.exe and rename it to Reflector.dll. You will need to do that everytime you update the version of Reflector.
Open the projects "CrossNetParser" and "Reflector.CrossNet" and update the references to the Reflector.dll that you just created.
Now we need to fix up the runtime references and the BCL references to CrossNetBenchmark, we are going to use CrossNetSystem for that. Open CrossNetBenchmark properties, go into the Configuration properties -> Linker -> Inputs
1. In additional dependencies, type: ..\$(ConfigurationName)\CrossNetRuntime.lib ..\$(ConfigurationName)\CrossNetSystem.lib
2. Build CrossNetBenchmark and there should be no compile / link error.
Now compile CrossNetParser and you should have 4 compile errors. This is expected. Since October 2007, Reflector API changed for the using keyword. For the moment, replace .Variable by .Expression. I'll send you a real fix if you are using "using" :) Sorry about that.
At that point you should be able to compile the whole issue without any error.
Copy Reflector.CrossNet.dll and CrossNet.dll where you have Reflector.exe. If you built the whole solution, the two dlls should be in the bin folder of Reflector.CrossNet.

Now that everything is configured correctly we can start to have fun.

Compile CSharpBenchmark. If you want to run it and see what the benchmark does:
1. Rename the method Test() in the class CSharpBenchmark._Benchmark.Benchmark.Test to Main()
2. Make the library a console application.
Revert these changes for the C++ conversion.
Once compiled, go in the folder Reflector.CrossNet and modify example.xml like this:
1. Change <OutputFolder>YouOutputPath</OutputFolder> to <OutputFolder>C:\TempFolder\CrossNetBenchmark\</OutputFolder>
2. Change <AssemblyToParse>FirstPath\FirstAssembly.dll</AssemblyToParse> to <AssemblyToParse>C:\TempFolder\CSharpBenchmark\bin\Debug\CSharpBenchmark.dll</AssemblyToParse>
3. Remove <AssemblyToParse>SecondPath\SecondAssembly.dll</AssemblyToParse>
4. Make sure that the paths are correct.
Run Reflector.exe, select .NET 2.0 runtime version (it should not matter but never know).
1. Go in View -> AddIns, and add Reflector.CrossNet to the list of add-ins.
2. If you regularly use Reflector make sure that the optimization is set to .NET 2.0 (not 3.0).
3. Close Reflector.exe.
4. Open the command prompt (run cmd.exe) and go in the folder where Reflector.exe is located (and the 2 other dlls).
5. Type: Reflector.exe /select:Reflector.CrossNet /crossnet:C:\TempFolder\Reflector.CrossNet\Example.xml
6. This will show Reflector UI for few seconds and should close it after a short beep.
7. If you go in CrossNetBenchmark folder you should see the C++ sources updated.
Go back to Visual Studio, compile again CrossNetBecnhmark, it should compile and link correctly (there may be some warnings).
1. You can now run the benchmark (C# code translated in C++)
Add step 3 as post-build step to the step 1. Switch the C++ code to release to have real performance. Modify the C# benchmark code or reference your own assembly instead. Remember to augment CrossNetSystem if you are using more CLR classes (and share with the community).

Enjoy and have fun!

Updated Wiki: Overview

OlivierNallet — Thu, 16 Apr 2009 04:25:19 GMT

Overview:

CrossNet is composed of several layers:

CrossNetParser:
This API reads a .NET assembly and generates unmanaged C++ files.
CrossNetParser is based on top of Reflector, an Add-In is provided.

CrossNetRuntime:
This C++ library is the core of CrossNet. You must compile and link this library against your generated C++ files.
CrossNetRuntime has a list of predefined .NET types already. The user cannot override them directly (except by changing CrossNetRuntime sources).

Additional things that you will need:

You will have to provide your own implementation of BCL (Base Class Library - like collections, Console, Diagnostics, etc...).
Your assembly will certainly need this BCL assembly to be able to compile and link. You can provide the BCL in several manners:

Use CrossNetSystem implementation. CrossNetSystem is another open source project. As of September 2007, this is not yet recommended as the very few classes are supported, and the implementation is certainly not correct. But it is expected to improve over time.

Use Mono's implementation. You can use CrossNetParser to transform Mono's BCL in C++, and integrate it in your process. I believe the Mono's license let you do that, you will have to check though.

Write your own. This is a huge task, you really don't want to do that (but that's your choice). It would be better if you were contributing to CrossNetSystem.

Note that if you are implementing BCL (or any other class) in C++, you take the risk for your code to be broken if CrossNet's API change.
You won't have this issue if you are using C#.

Please do not disassemble Microsoft's BCL implementation (with CrossNet or anything else). I don't think you have the rights. Please don't do it.
In any case, there will be some technical issues - First CrossNetParser would generate incorrect C++ code in the most complex cases
of the Microsoft assemblies, and also one would have to implement many external methods. A lot of time will be spent modifying by hand the generated C++ code.
Instead, please contribute to CrossNetSystem.

Before you can execute any code in your assembly, you will also have to initialize CrossNetRuntime.
This initialization is mostly setting up the memory buffers and few callbacks, as well as implement the class System.Type.

You can find here more details:

How do I get started?
Why generate C++?
Can you describe the workflow?
How do I use several assemblies together?
How does the Garbage Collector work?
What about .NET 3.0 and later?
Do you have some benchmarks?
What is the memory usage?
How can I contribute?
Do you have some unit-tests?
How can I create my own user's policy in the parser?
Examples of generated code.

If you have more questions (I'm sure you do), you can look at the code, examples, and unit-tests.
Don't hesitate to use the forums as well.

Updated Wiki: Important notes!

OlivierNallet — Thu, 16 Apr 2009 04:23:24 GMT

Important notes!

The project has been public since September 2007, and as such, you must expect some issues. ;)
Please use the forum if you have any question or feedback!

The tests are done on PC with VS2005. Do expect some issues on X360 / PS3 / Wii or even any other C++ compiler. I unfortunately currently don't have the time to test any other compiler. I also don't have access to console devkits at home, so bear with me. Please report to the issue tracker any compile error that you have as I'm sure they'll be easy to fix.

Although I spent quite some time on CrossNet, there are still many many cases where the C++ code is incorrectly generated, or places where the runtime is buggy (or even not implemented at all). Even if a lot of cases are covered already, I want to set your expectations low for the moment so you don't have bad surprises. ;)

CrossNet is using Reflector. Even if this tool is of very high quality, there are still some known bugs that should be fixed soon. If your assembly can't be parsed correctly, try to compile it with optimization and check overflow turned off, sometime that helps.

Some pieces are simply not finished (look at the To do! list). If you really need that particular piece ASAP (either correct parsing or correct runtime behavior), again report it on the issue tracker.

In some rare optimization cases, the C++ compiler might be too smart (or too dumb depending on how you see it ;). It might save an offseted address on the stack for some objects in order to access members more quickly later. Unfortunately this can actually make the GC miss the object when crawling the stack. I added some code to actually detect and solve this case (or at least the only I have seen so far on VS2005). If when you run your code in release only, you see that one of your local object has been collected after a GC, try to reduce your optimization settings and see if that fixes the issue. If you can, send a simple example reproducing the issue so we can see how we can generalize the solution.

Here is what you should do if you encounter some issues:

Try to create the simplest test case and add it to the issue tracker. It is very important! Often it takes more time to reproduce those issues than actually fixing them.
If the generated C++ code doesn't compile with your compiler, provide an example of how the code should be generated for your compiler to accept it. This way, I will be able to fix the issue even if I don't have access to your compiler.
Change / Simplify your code a bit to use more intermediate variables / statements.
Change your compile options (like turn optimization / check overflow off). Remember that the code is optimized by the C+ compiler at the end, so turning optimization off in the .NET side won't actually change the performance of the generated code.

Updated Wiki: Home

OlivierNallet — Thu, 16 Apr 2009 04:14:55 GMT

CrossNet is a cross platform .NET runtime.
It parses .NET assemblies and generates unmanaged C++ code that can be compiled on any standard C++ compiler.

More than 95% of the .NET 2.0 features are actually "emulated" in C++. CrossNet does not produce managed C++, the generated code is pure ANSI C++.
Even if that's only an emulation of .NET, the performance and memory usage are usually in the same range as C++ / .NET.
It is important to note that CrossNet's parser is a Reflector Add-In.

Examples of generated code.

CrossNet is not the same thing as Mono:

CrossNet emulates the .NET runtime but the goal is not to write the full .NET API. Some very rarely used features might not be emulated correctly.
Some tiny portions of the BCL (Base Class Library) have been implemented in C++, but the purpose was mostly for the development of unit-tests.
When using CrossNet, one must provide some BCL implementation (or at least for the classes / methods used).
One can either augment the CrossNet emulation of BCL by using CrossNetSystem (not recommended yet), use Mono's or write own implementation.

CrossNet can be used where .NET / Mono might not be the best fit:

The platform is not standard and doesn't support .NET or Mono.
JIT cannot be implemented on the platform.
The platform has some memory constraints.
Best performance is needed and interpretation is not an option (i.e. Mint or MicroFramework might be too slow).
A simple code that can be customized and facilitate user's policy is a plus (memory tracking for example...).
There is a need for direct interaction with C++ code / compiler.
The code needs to be easily understandable and maintainable (or could be used to learn how .NET behavior can be emulated).

Important notes!

Please look at the overview, there is a lot more information and links there!

Features supported
Features to be supported soon
Features not expected to be supported soon

UPDATED WIKI: Features to be supported soon

OlivierNallet — Sun, 14 Oct 2007 06:29:58 GMT

Features to be supported (soon):

Asynchronous delegates
Some uncommon fixed syntax
GC defragmentation / generational
__arglist, __makeref, __reftype, __refvalue
ToString() on enum values / type
Weak references
Full exceptions

Will be supported with next change set (around end of September).

Exceptions with implementation not using C++ exceptions.
Exceptions for null dereference, divide by zero, etc...
StructLayout
Operations with System.Enum
Numerous bug fixes (and more complex unit tests to pass)

UPDATED WIKI: Features supported

OlivierNallet — Sun, 14 Oct 2007 06:29:07 GMT

Features supported (with .NET 2.0 as base):

Delegates
Interfaces
Generics (Few restrictions)

Static constructors / members for generic types.

.NET Arrays
Properties / indexers
.NET Strings / String pooling / Switch on strings
Boxing / Unboxing
Variable size enums
Foreach and enumerators
is / as / cast / GetType() / typeof
Events
.NET Operators
Method calls on primitive types
Virtual calls in constructors
Coalesce
Nullable structures
Extern methods

Directly pointing to user defined C++ method
Also used during PInvoke.

Keyword collision (corresponds to @label in C#)
GC
Unsafe code (mostly supported)
Finalizers
Static constructors
Anonymous methods
Global namespace
Exceptions (Finally partially supported)

UPDATED WIKI: Overview

OlivierNallet — Sun, 14 Oct 2007 06:25:24 GMT

Overview:

CrossNet is composed of several layers:

CrossNetParser:
This API reads a .NET assembly and generates unmanaged C++ files.
CrossNetParser is based on top of Reflector, an Add-In is provided.

CrossNetRuntime:
This C++ library is the core of CrossNet. You must compile and link this library against your generated C++ files.
CrossNetRuntime has a list of predefined .NET types already. The user cannot override them directly (except by changing CrossNetRuntime sources).

Additional things that you will need:

You will have to provide your own implementation of BCL (Base Class Library - like collections, Console, Diagnostics, etc...).
Your assembly will certainly need this BCL assembly to be able to compile and link. You can provide the BCL in several manners:

Use CrossNetSystem implementation. CrossNetSystem is another open source project. As of September 2007, this is not yet recommended as the very few classes are supported, and the implementation is certainly not correct. But it is expected to improve over time.

Use Mono's implementation. You can use CrossNetParser to transform Mono's BCL in C++, and integrate it in your process. I believe the Mono's license let you do that, you will have to check though.

Write your own. This is a huge task, you really don't want to do that (but that's your choice). It would be better if you were contributing to CrossNetSystem.

How do I get started?
Why generate C++?
Can you describe the workflow?
How do I use several assemblies together?
How does the Garbage Collector work?
What about .NET 3.0 and later?
Do you have some benchmarks?
What is the memory usage?
How can I contribute?
Do you have some unit-tests?
How can I create my own user's policy in the parser?
Examples of generated code.

If you have more questions (I'm sure you do), you can look at the code, examples, and unit-tests.
Don't hesitate to use the forums as well.

UPDATED WIKI: Home

OlivierNallet — Sun, 14 Oct 2007 06:21:29 GMT

CrossNet is a cross platform .NET runtime.
It parses .NET assemblies and generates unmanaged C++ code that can be compiled on any standard C++ compiler.

More than 95% of the .NET 2.0 features are actually "emulated" in C++. CrossNet does not produce managed C++, the generated code is pure ANSI C++.
Even if that's only an emulation of .NET, the performance and memory usage are usually in the same range as C++ / .NET.
It is important to note that CrossNet's parser is a Reflector Add-In.

Examples of generated code.

CrossNet is not the same thing as Mono:

CrossNet emulates the .NET runtime but the goal is not to write the full .NET API. Some very rarely used features might not be emulated correctly.
Some tiny portions of the BCL (Base Class Library) have been implemented in C++, but the purpose was mostly for the development of unit-tests.
When using CrossNet, one must provide some BCL implementation (or at least for the classes / methods used).
One can either augment the CrossNet emulation of BCL by using CrossNetSystem (not recommended yet), use Mono's or write own implementation.

CrossNet can be used where .NET / Mono might not be the best fit:

The platform is not standard and doesn't support .NET or Mono.
JIT cannot be implemented on the platform.
The platform has some memory constraints.
Best performance is needed and interpretation is not an option (i.e. Mint or MicroFramework might be too slow).
A simple code that can be customized and facilitate user's policy is a plus (memory tracking for example...).
There is a need for direct interaction with C++ code / compiler.
The code needs to be easily understandable and maintainable (or could be used to learn how .NET behavior can be emulated).

Important notes!

Please look at the overview, there is a lot more information and links there!

Features supported
Features to be supported soon
Features not expected to be supported soon

UPDATED WIKI: Home

OlivierNallet — Mon, 01 Oct 2007 05:50:48 GMT

CrossNet is a cross platform .NET runtime.
It parses .NET assemblies and generates unmanaged C++ code that can be compiled on any standard C++ compiler.

More than 95% of the .NET 2.0 features are actually "emulated" in C++. CrossNet does not produce managed C++, the generated code is pure ANSI C++.
Even if that's only an emulation of .NET, the performance and memory usage are usually in the same range as C++ / .NET.
It is important to note that CrossNet is using Reflector's public API (undocumented).

Examples of generated code.

CrossNet is not the same thing as Mono:

CrossNet emulates the .NET runtime but the goal is not to write the full .NET API. Some very rarely used features might not be emulated correctly.
Some tiny portions of the BCL (Base Class Library) have been implemented in C++, but the purpose was mostly for the development of unit-tests.
When using CrossNet, one must provide some BCL implementation (or at least for the classes / methods used).
One can either augment the CrossNet emulation of BCL by using CrossNetSystem (not recommended yet), use Mono's implementation or write his/her own.

CrossNet can be used where .NET / Mono might not be the best fit:

The platform is not standard and doesn't support .NET or Mono.
JIT cannot be implemented on the platform.
The platform has some memory constraints.
Best performance is needed and interpretation is not an option (i.e. Mint or MicroFramework might be too slow).
A simple code that can be customized and facilitate user's policy is a plus (memory tracking for example...).
There is a need for direct interaction with C++ code / compiler.
The code needs to be easily understandable and maintainable (or could be used to learn how .NET behavior can be emulated).

Important notes!

Please look at the overview, there is a lot more information and links there!

Features supported
Features to be supported soon
Features not expected to be supported soon

UPDATED WIKI: Home

OlivierNallet — Mon, 01 Oct 2007 05:46:17 GMT

CrossNet is a cross platform .NET runtime. It parses .NET assemblies and generates unmanaged C++ code that can be compiled on any standard C++ compiler.

More than 95% of the .NET 2.0 features are actually "emulated" in C++. CrossNet does not produce managed C++, the generated code is pure ANSI C++.
Even if that's only an emulation of .NET, the performance and memory usage are usually in the same range as C++ / .NET.
It is important to note that CrossNet is using Reflector's public API (undocumented).

Examples of generated code.

CrossNet is not the same thing as Mono:

CrossNet emulates the .NET runtime but the goal is not to write the full .NET API. Some very rarely used features might not be emulated correctly.
Some tiny portions of the BCL (Base Class Library) have been implemented in C++, but the purpose was mostly for the development of unit-tests.
When using CrossNet, one must provide some BCL implementation (or at least for the classes / methods used).
One can either augment the CrossNet emulation of BCL by using CrossNetSystem (not recommended yet), use Mono's implementation or write his/her own.

CrossNet can be used where .NET / Mono might not be the best fit:

The platform is not standard and doesn't support .NET or Mono.
JIT cannot be implemented on the platform.
The platform has some memory constraints.
Best performance is needed and interpretation is not an option (i.e. Mint or MicroFramework might be too slow).
A simple code that can be customized and facilitate user's policy is a plus (memory tracking for example...).
There is a need for direct interaction with C++ code / compiler.
The code needs to be easily understandable and maintainable (or could be used to learn how .NET behavior can be emulated).

Important notes!

Please look at the overview, there is a lot more information and links there!

Features supported
Features to be supported soon
Features not expected to be supported soon

UPDATED WIKI: Home

OlivierNallet — Mon, 01 Oct 2007 05:17:45 GMT

CrossNet parses .NET assemblies and generates unmanaged C++ code that can be compiled on any standard C++ compiler. That makes CrossNet a cross platform .NET runtime.

More than 95% of the .NET 2.0 features are actually "emulated" in C++. CrossNet does not produce managed C++, the generated code is pure ANSI C++.
Even if that's only an emulation of .NET, the performance and memory usage are usually in the same range as C++ / .NET.
It is important to note that CrossNet is using Reflector's public API (undocumented).

Examples of generated code.

CrossNet is not the same thing as Mono:

CrossNet emulates the .NET runtime but the goal is not to write the full .NET API. Some very rarely used features might not be emulated correctly.
Some tiny portions of the BCL (Base Class Library) have been implemented in C++, but the purpose was mostly for the development of unit-tests.
When using CrossNet, one must provide some BCL implementation (or at least for the classes / methods used).
One can either augment the CrossNet emulation of BCL by using CrossNetSystem (not recommended yet), use Mono's implementation or write his/her own.

CrossNet can be used where .NET / Mono might not be the best fit:

The platform is not standard and doesn't support .NET or Mono.
JIT cannot be implemented on the platform.
The platform has some memory constraints.
Best performance is needed and interpretation is not an option (i.e. Mint or MicroFramework might be too slow).
A simple code that can be customized and facilitate user's policy is a plus (memory tracking for example...).
There is a need for direct interaction with C++ code / compiler.
The code needs to be easily understandable and maintainable (or could be used to learn how .NET behavior can be emulated).

Important notes!

Please look at the overview, there is a lot more information and links there!

Features supported
Features to be supported soon
Features not expected to be supported soon

UPDATED WIKI: To do!

OlivierNallet — Mon, 01 Oct 2007 05:13:10 GMT

Backlog:

From now on, I'm going to use the issue tracker for the status of my work.
This page is now just my backlog of things I shoud do one day as lower priority.
Don't hesitate to move some of these on the issue tracker if you feel that they are important!

Missing features / Bugs:

Review buffer construct of co8705constains_obj
Must add tracing in Hashtable and Enumerator if not done already.
+ with pointers with one of them is casted with reinterpret_cast<T *>. We might create this issue during the parsing.
Fix issue when a derived class method hides a method from the base class. -> Make LinkedResource unit test work again

I guess the solution would be detect the hidden function and use the C++ keyword "using" to make them reachable. That's not pretty nor efficient at parsing time. :(
The other solution is to cast to the base type during the call.

Improve test16 / test88 / event_tests
Handle int * * p correctly.
Detect memory leaks after shutdown
Investigate why we need 40 MB or so to run and not 15 MB when running the benchmark. (Bug in GC / or simply due to fragmentation?)

Low priority:

Add support for typeof(X<>) with X<> representing the generic type and not a specific implementation.

Actually I'm wondering what is the interest of supporting this if we don't have reflection nor dynamic type generation.

Checked is not supported

Probably will never be supported.

Interestingly int * [] is partially supported in .NET. We can't convert an item to object. (BTW that's exactly where Crossnet fails to compile - Could we solve it by some traits?).
Handle __arglist, __makeref, __reftype, __refvalue. See if Reflector handles that correctly now.

These should only be used in managed C++, not a common usage.

Improve switch on strings, there is currently an extremely small probability that the switch / case doesn't behave correctly. Unit tests added to list the various implementations.
Implement GenerateCodeArgumentList() in System::String::Concat()

Reflector:

Reflector is missing the conversion to 64 bits, like in System.IO.BinaryReader.ReadInt64.

-> Sent to Lutz Roeder - Reflector

Issue with some fixed syntax (with C# code like fixed (void * buffer = intArray) ...)

-> Sent to Lutz Roeder - Reflector

Issue with ++ (TestString / test_42) - This issue doesn't seem to happen when the assembly is compiled in debug and overflow check is off.

-> Sent to Lutz Roeder - Reflector

Issue with ++ with unsafe pointers. This issue seems to happen even in debug and overflow check is off.

-> Didn't send to Lutz yet, waiting for the ++ fix above to see if this is going to fix this issue as well.

Issue with properties get / set with ++ and return value (like return (MyProp++); This is actually a get, +1, dup, set and return. In some cases, Reflector returns invalid code and CrossNet doesn't recover.

Issue with CrossNet and Reflector. Will have to figure this out later when ++ is solved in general.

In optimized assembly, with new U() where U is a generic type is not disassembled correctly.

Optimizations:

Readonly should be const for primitive types. Like BitConverter.IsLittleEndian.
Improve parsing to get rid of the empty function _Trace_ (if there is no traceable fields in the class).

Could detect that during GetDependencies()

Add perm allocations (like for global strings or types). Do not trace them...

Although generational would pretty much do the same.

Const int should be declared in headers instead of cpp.
Detect cases where cast result is known and a fast cast is acceptable
Remove virtual call (fully qualify the type?) for sealed classes
Clarify usage of delegate and multi-cast delegate / optimize.
Add dictionary in Provider.cs / GetEmbeddedType().
When a struct explictly implements a method of an interface, it will mark the function as virtual. No method should be virtual in a struct.

The issue is the same for classes. Is it the intended behavior even for a class?

Make sure handler for event is not duplicated.
Use traits for generic code when doing an interface call on a struct.

As structs can't be overriden, the interface method could be known at compile time and handled correctly by traits.
There is some work regarding the macro for interface call, but it would mean interface call on a struct in a generic would be as fast as a normal call.

Trace the static members on a generic only one time (and not for every instance).
Find ways to get rid of the original anonymous method / class as it's duplicated.

Refactoring / Cleaning:

See if we can Deactivate ->() for the structures.
typedef void * InterfaceMap;
Look for [=]. We should be able to remove this marker.
Find a way to simplify crossnet_box / unbox struct boxing / unboxing

UPDATED WIKI: Generics

OlivierNallet — Mon, 24 Sep 2007 04:56:43 GMT

Generics

Generics are much more complicated than what they seem. They are not Java syntactic sugar, .NET JIT actually understands generics and do great things with it.
CrossNet uses C++ templates to emulate generics. There are some limitations though, but in most cases you probably won't notice them.
Fortunately C++ templates are more lenient that .NET generics, so constraints are actually not needed (but we could actually use them to do some optimizations).

First let's talk about what is not supported by CrossNet:

class TestGenericVirtual
{
    public virtual T Foo<T>(T a)
    {
        return (a);
    }
}

The reason is that in C++, virtual functions can't be templated.

And by extension, this is not supported:

interface ITestGenericMethod
{
    string Foo<V>(string a, V b);
}

Interfaces are emulated with abstract classes, all the methods in the interface are also abstract. The interface itself can be generic.

So this is perfectly supported:

interface ITestSimpleGenericInterface<U>
{
    U Foo(U a);
}

The two other unsupported cases are:

Generic types dynamically created (doesn't fit well with statically compiled templates ;).
Static members for generic types (Will be supported with next change set around end of September).

Also note that .NET supports overloading of name for generics, the number of generic arguments differentiates the class / method (there is no default parameter in .NET).

Example of C# code:

public class Foo
{
    public void Bar()
    {
    }
    public void Bar<X>()
    {
    }
    public void Bar<X, Y>()
    {
    }
    public void Bar<X, Y, Z>()
    {
    }
}

Generated C++ code:

class TestGenericCollision__Foo : public ::System::Object
{
    ...
    public:
    ::System::Void Bar();
    public:
    template <typename X>
    ::System::Void Bar__G1();
    public:
    template <typename X, typename Y>
    ::System::Void Bar__G2();
    public:
    template <typename X, typename Y, typename Z>
    ::System::Void Bar__G3();
    ...
};

As you can see __G? (where ? represents the number of generic arguments) is appended to differentiate the generic from the non-generic function.
You can have some very complicated syntax but CrossNet is hiding everything for you.

CrossNet manages creation of System.Type, interface map, interface ID dynamically for generic types.

C# Code:

static public void gmeth1<T>()
{
    Console.WriteLine(typeof(Set<T>));
    Console.WriteLine(typeof(Map<T, T>));
    Console.WriteLine(typeof(T));
    gmeth2<T, Set<T>>();
    gmeth2<Set<T>, T>();
}

Generated C++ code:

template <typename T>
::System::Void CrossNetUnitTest::Generic::TestRegressionGenmeth4__M::gmeth1__G1()
{
    ::System::Console::WriteLine(CN_TYPEOF(::CrossNetUnitTest::Generic::TestRegressionGenmeth4__Set__G1<T>));
    ::System::Console::WriteLine(CN_TYPEOF(::CrossNetUnitTest::Generic::TestRegressionGenmeth4__Map__G2<__W2__(T, T)>));
    ::System::Console::WriteLine(CN_TYPEOF(T));
    ::CrossNetUnitTest::Generic::TestRegressionGenmeth4__M::gmeth2__G2<__W2__(T, ::CrossNetUnitTest::Generic::TestRegressionGenmeth4__Set__G1<T> *)>();
    ::CrossNetUnitTest::Generic::TestRegressionGenmeth4__M::gmeth2__G2<__W2__(::CrossNetUnitTest::Generic::TestRegressionGenmeth4__Set__G1<T> *, T)>();
}

Note the macro CN_TYPEOF to get the corresponding System::Type object from the C++ type.
The macro _W?_ is just a wrapper around the template parameters. We are using the wrapper macro because C++ macros don't recognize < > to describe template parameters as partitioner.

So this would not compile:

    ::System::Console::WriteLine(CN_TYPEOF(::CrossNetUnitTest::Generic::TestRegressionGenmeth4__Map__G2<T, T>));

Because the preprocessor would undertand it as 2 parameters for the macro CN_TYPEOF that can receive only one parameter.
I guess we could use variadic macros to get around that but not all C++ compiler does support it.

Finally there are much more tricks to make the generics work, but I will describe them later...

UPDATED WIKI: Features supported

OlivierNallet — Mon, 24 Sep 2007 04:42:27 GMT

Features supported (with .NET 2.0 as base):

Delegates
Interfaces
Generics (Some restrictions)
.NET Arrays
Properties / indexers
.NET Strings / String pooling / Switch on strings
Boxing / Unboxing
Variable size enums
Foreach and enumerators
is / as / cast / GetType() / typeof
Events
.NET Operators
Method calls on primitive types
Virtual calls in constructors
Coalesce
Nullable structures
Extern methods

Directly pointing to user defined C++ method
Also used during PInvoke.

Keyword collision (corresponds to @label in C#)
GC
Unsafe code (mostly supported)
Finalizers
Static constructors
Exceptions (Finally partially supported)

UPDATED WIKI: Features to be supported soon

OlivierNallet — Mon, 24 Sep 2007 04:41:03 GMT

Features to be supported (soon):

Asynchronous delegates
Anonymous methods

Will be supported with next change set (around end of September).

Some uncommon fixed syntax
GC defragmentation / generational
__arglist, __makeref, __reftype, __refvalue
Static constructors for generic types

Will be supported with next change set (around end of September).

ToString() on enum values / type
Weak references
Global namespace

Will be supported with next change set (around end of September).

Full exceptions

Will be supported with next change set (around end of September).

Exceptions with implementation not using C++ exceptions.
Exceptions for null dereference, divide by zero, etc...
StructLayout
Operations with System.Enum
Numerous bug fixes (and more complex unit tests to pass)

UPDATED WIKI: To do!

OlivierNallet — Mon, 24 Sep 2007 04:38:54 GMT

TO DO list:

That's my list of items I'm working on.
Assume that anything listed here just doesn't work (just so I set your expectations low ;)

Missing features / Bugs:

Implement remaining functions for Array, String and StringBuilder. Those classes can't be overriden by the user.

Currently only a very minimum set is implemented (and not thoroughly tested).

Review buffer construct of co8705constains_obj
Must add tracing in Hashtable and Enumerator if not done already.
+ with pointers with one of them is casted with reinterpret_cast<T *>. We might create this issue during the parsing.
Fix issue when a derived class method hides a method from the base class. -> Make LinkedResource unit test work again

I guess the solution would be detect the hidden function and use the C++ keyword "using" to make them reachable. That's not pretty nor efficient at parsing time. :(
The other solution is to cast to the base type during the call.

Improve test16 / test88 / event_tests
Asynchronous delegates

-> Need thread safety first though. We could actually accept the convention call, and call it just synchronously at first.

Handle int * * p correctly.
Implement finally with exceptions. catch is surrounded by another try catch. The sub-catch call the finally statement then throw the exception again.

Done, but finally is currently not called if there is a return statement :( More work needed...

Implement ToString() for enum values / type

Don't know how critical this really is.

Detect memory leaks after shutdown
Investigate why we need 40 MB or so to run and not 15 MB when running the benchmark. (Bug in GC / or simply due to fragmentation?)
Add unit-test for anonymous methods and generic types.

Low priority:

Add support for typeof(X<>) with X<> representing the generic type and not a specific implementation.

Actually I'm wondering what is the interest of supporting this if we don't have reflection nor dynamic type generation.

Checked is not supported

Probably will never be supported.

Implement weak references.

Probably tied to moving GC.

Interestingly int * [] is partially supported in .NET. We can't convert an item to object. (BTW that's exactly where Crossnet fails to compile - Could we solve it by some traits?).
Handle __arglist, __makeref, __reftype, __refvalue. See if Reflector handles that correctly now.

These should only be used in managed C++, not a common usage.

Improve switch on strings, there is currently an extremely small probability that the switch / case doesn't behave correctly. Unit tests added to list the various implementations.
Implement GenerateCodeArgumentList() in System::String::Concat()
StructLayout
Enum as base class.

Reflector:

Reflector is missing the conversion to 64 bits, like in System.IO.BinaryReader.ReadInt64.

-> Sent to Lutz Roeder - Reflector

Issue with some fixed syntax (with C# code like fixed (void * buffer = intArray) ...)

-> Sent to Lutz Roeder - Reflector

Issue with ++ (TestString / test_42) - This issue doesn't seem to happen when the assembly is compiled in debug and overflow check is off.

-> Sent to Lutz Roeder - Reflector

Issue with ++ with unsafe pointers. This issue seems to happen even in debug and overflow check is off.

-> Didn't send to Lutz yet, waiting for the ++ fix above to see if this is going to fix this issue as well.

Issue with properties get / set with ++ and return value (like return (MyProp++); This is actually a get, +1, dup, set and return. In some cases, Reflector returns invalid code and CrossNet doesn't recover.

Issue with CrossNet and Reflector. Will have to figure this out later when ++ is solved in general.

In optimized assembly, with new U() where U is a generic type is not disassembled correctly.

Optimizations:

Readonly should be const for primitive types. Like BitConverter.IsLittleEndian.
Improve parsing to get rid of the empty function _Trace_ (if there is no traceable fields in the class).

Could detect that during GetDependencies()

Implement moving GC
Implement generational GC
Add perm allocations (like for global strings or types). Do not trace them...

Although generational would pretty much do the same.

Add flag for finalizer? Revisit finalizers.
Const int should be declared in headers instead of cpp.
Detect cases where cast result is known and a fast cast is acceptable
Remove virtual call (fully qualify the type?) for sealed classes
Clarify usage of delegate and multi-cast delegate / optimize.
Add dictionary in Provider.cs / GetEmbeddedType().
When a struct explictly implements a method of an interface, it will mark the function as virtual. No method should be virtual in a struct.

The issue is the same for classes. Is it the intended behavior even for a class?

Make sure handler for event is not duplicated.
Use traits for generic code when doing an interface call on a struct.

As structs can't be overriden, the interface method could be known at compile time and handled correctly by traits.
There is some work regarding the macro for interface call, but it would mean interface call on a struct in a generic would be as fast as a normal call.

Trace the static members on a generic only one time (and not for every instance).
Find ways to get rid of the original anonymous method / class as it's duplicated.

Refactoring / Cleaning:

See if we can Deactivate ->() for the structures.
typedef void * InterfaceMap;
Look for [=]. We should be able to remove this marker.
Find a way to simplify crossnet_box / unbox struct boxing / unboxing

Done: (to be released with next change set - around end of September)

Implemented default Equals() on struct.

Implemented correct Equals() and GetHashCode() as well for objects as I misinterpreted the behavior. Added unit-tests to validate that.

Class deriving from an instantiated generic interface compiles (wrapper used typename but we were not in a template definition).
Class deriving from the same interface multiple times (like IEnumerable<int> and IEnumerable<double>) is now handled properly.
Found the correct order between GetEnumerator(), IEnumerator and IEnumerator() in foreach statement

Unit test completely enabled as issues fixed above are fixed.

Fixed case where explicit interface could be shadowed by implicit implementation of an interface method.
Strings with embedded '\0' are now initialized correctly.
Global namespace is now handled correctly.
Fixed issue with opExplicitIntPtr from void *
Fixed implicit cast with generics; the generated function name was incorrect.
Array::TestArraysClass__TestRef now compiles correctly when the assembly is compiled in release.
Cleaned generation of arrays and template so ">>" is not generated in the incorrect places.

(VC++ 2005 compiles correctly with two nested templates - !- but I don't think it's ANSI C++).

Added unit-test to compare content / hashcode between boxed / unboxed type (primitive type, enums, user struct, generic user struct, strings).

IEquatable is part of the test as well... The test is done using a generic to test things even further.

T[] implements correctly IList<T>, IList, ICollection, ICloneable. Unit-tests added (mostly covered). Still have IEnumerable and IEnumerable<> to finalize.
Finished to rename types with __ when they were encapsulated in the namespace CrossNetRuntime.
Added unit test for struct + interface call / Boxed object.
Improved unit-test for struct construction (regarding declaration / static field initialization / field initialization / inherited constructor).
Fixed typeof in generics, now one macro encapsulates correctly primitive types, structures and classes, with generics it was previously impossible to determine the correct macro.
Added CrossNetRuntime::Tracer::DoTrace() helper method to trace objects (very useful for generic members).

It uses traits, so that's resolved at compile time and is a no-op where there is no need to trace.

Handled static constructors and static members for generic types.

For the concerned generics, static constructors are called at every construction (and a flag make sure that we call the init only one time).
The current implementation is limited, it might create link errors if several assemblies using the generic with static constructors are compiled in different obj files. This can be improved later as needed.
Currently static members are traced when we are tracing each instance (that mean they can be traced several times). This will be optimized over time.
Accessing directly static members of a generic type may not return a correct result if a corresponding generic instance has not been created earlier (static constructor is called at instance creation).
Beside adding a check before each static member access I don't think there is an easy fix.

Anonymous methods are now supported!

There was more work than expected as I ended up having to generate what the C# compiler does. Pretty nice design though, very transparent for the user. Lot of work for the compiler ;)
Expect some issues if the declaring type is generic as I didn't test that yet. Should be easy to fix though.

Re-enabled Mono's unit tests.

55 unit tests have been disabled on around 230 unit-tests. The reason is because the features are not supported yet:
Unit-tests using things like: Reflection, Multi-threading, exception on divide by zero, attributes, CodeGen, StructLayout, Asynchronous delegates, __arglist, DateTime implementation, support for nan.
All these features are already documented as not supported or in the to do list...

UPDATED WIKI: To do!

OlivierNallet — Mon, 24 Sep 2007 04:34:21 GMT

TO DO list:

That's my list of items I'm working on.
Assume that anything listed here just doesn't work (just so I set your expectations low ;)

Missing features / Bugs:

Implement remaining functions for Array, String and StringBuilder. Those classes can't be overriden by the user.

Currently only a very minimum set is implemented (and not thoroughly tested).

Review buffer construct of co8705constains_obj
Must add tracing in Hashtable and Enumerator if not done already.
+ with pointers with one of them is casted with reinterpret_cast<T *>. We might create this issue during the parsing.
Fix issue when a derived class method hides a method from the base class. -> Make LinkedResource unit test work again

I guess the solution would be detect the hidden function and use the C++ keyword "using" to make them reachable. That's not pretty nor efficient at parsing time. :(
The other solution is to cast to the base type during the call.

Improve test16 / test88 / event_tests
Asynchronous delegates

-> Need thread safety first though. We could actually accept the convention call, and call it just synchronously at first.

Handle int * * p correctly.
Implement finally with exceptions. catch is surrounded by another try catch. The sub-catch call the finally statement then throw the exception again.

Done, but finally is currently not called if there is a return statement :( More work needed...

Implement ToString() for enum values / type

Don't know how critical this really is.

Detect memory leaks after shutdown
Investigate why we need 40 MB or so to run and not 15 MB when running the benchmark. (Bug in GC / or simply due to fragmentation?)
Add unit-test for anonymous methods and generic types.

Low priority:

Add support for typeof(X<>) with X<> representing the generic type and not a specific implementation.

Actually I'm wondering what is the interest of supporting this if we don't have reflection nor dynamic type generation.

Checked is not supported

Probably will never be supported.

Implement weak references.

Probably tied to moving GC.

Interestingly int * [] is partially supported in .NET. We can't convert an item to object. (BTW that's exactly where Crossnet fails to compile - Could we solve it by some traits?).
Handle __arglist, __makeref, __reftype, __refvalue. See if Reflector handles that correctly now.

These should only be used in managed C++, not a common usage.

Improve switch on strings, there is currently an extremely small probability that the switch / case doesn't behave correctly. Unit tests added to list the various implementations.
Implement GenerateCodeArgumentList() in System::String::Concat()

Reflector:

Reflector is missing the conversion to 64 bits, like in System.IO.BinaryReader.ReadInt64.

-> Sent to Lutz Roeder - Reflector

Issue with some fixed syntax (with C# code like fixed (void * buffer = intArray) ...)

-> Sent to Lutz Roeder - Reflector

test59 - Reflector doesn't return correctly signed int64

-> Sent to Lutz Roeder - Reflector

Issue with ++ (TestString / test_42) - This issue doesn't seem to happen when the assembly is compiled in debug and overflow check is off.

-> Sent to Lutz Roeder - Reflector

Issue with ++ with unsafe pointers. This issue seems to happen even in debug and overflow check is off.

-> Didn't send to Lutz yet, waiting for the ++ fix above to see if this is going to fix this issue as well.

Issue with properties get / set with ++ and return value (like return (MyProp++); This is actually a get, +1, dup, set and return. In some cases, Reflector returns invalid code and CrossNet doesn't recover.

Issue with CrossNet and Reflector. Will have to figure this out later when ++ is solved in general.

In optimized assembly, with new U() where U is a generic type is not disassembled correctly.

Optimizations:

Readonly should be const for primitive types. Like BitConverter.IsLittleEndian.
Improve parsing to get rid of the empty function _Trace_ (if there is no traceable fields in the class).

Could detect that during GetDependencies()

Implement moving GC
Implement generational GC
Add perm allocations (like for global strings or types). Do not trace them...

Although generational would pretty much do the same.

Add flag for finalizer? Revisit finalizers.
Const int should be declared in headers instead of cpp.
Detect cases where cast result is known and a fast cast is acceptable
Remove virtual call (fully qualify the type?) for sealed classes
Clarify usage of delegate and multi-cast delegate / optimize.
Add dictionary in Provider.cs / GetEmbeddedType().
When a struct explictly implements a method of an interface, it will mark the function as virtual. No method should be virtual in a struct.

The issue is the same for classes. Is it the intended behavior even for a class?

Make sure handler for event is not duplicated.
Use traits for generic code when doing an interface call on a struct.

As structs can't be overriden, the interface method could be known at compile time and handled correctly by traits.
There is some work regarding the macro for interface call, but it would mean interface call on a struct in a generic would be as fast as a normal call.

Trace the static members on a generic only one time (and not for every instance).
Find ways to get rid of the original anonymous method / class as it's duplicated.

Refactoring / Cleaning:

See if we can Deactivate ->() for the structures.
typedef void * InterfaceMap;
Look for [=]. We should be able to remove this marker.
Find a way to simplify crossnet_box / unbox struct boxing / unboxing

Done: (to be released with next change set - around end of September)

Implemented default Equals() on struct.

Implemented correct Equals() and GetHashCode() as well for objects as I misinterpreted the behavior. Added unit-tests to validate that.

Class deriving from an instantiated generic interface compiles (wrapper used typename but we were not in a template definition).
Class deriving from the same interface multiple times (like IEnumerable<int> and IEnumerable<double>) is now handled properly.
Found the correct order between GetEnumerator(), IEnumerator and IEnumerator() in foreach statement

Unit test completely enabled as issues fixed above are fixed.

Fixed case where explicit interface could be shadowed by implicit implementation of an interface method.
Strings with embedded '\0' are now initialized correctly.
Global namespace is now handled correctly.
Fixed issue with opExplicitIntPtr from void *
Fixed implicit cast with generics; the generated function name was incorrect.
Array::TestArraysClass__TestRef now compiles correctly when the assembly is compiled in release.
Cleaned generation of arrays and template so ">>" is not generated in the incorrect places.

(VC++ 2005 compiles correctly with two nested templates - !- but I don't think it's ANSI C++).

Added unit-test to compare content / hashcode between boxed / unboxed type (primitive type, enums, user struct, generic user struct, strings).

IEquatable is part of the test as well... The test is done using a generic to test things even further.

T[] implements correctly IList<T>, IList, ICollection, ICloneable. Unit-tests added (mostly covered). Still have IEnumerable and IEnumerable<> to finalize.
Finished to rename types with __ when they were encapsulated in the namespace CrossNetRuntime.
Added unit test for struct + interface call / Boxed object.
Improved unit-test for struct construction (regarding declaration / static field initialization / field initialization / inherited constructor).
Fixed typeof in generics, now one macro encapsulates correctly primitive types, structures and classes, with generics it was previously impossible to determine the correct macro.
Added CrossNetRuntime::Tracer::DoTrace() helper method to trace objects (very useful for generic members).

It uses traits, so that's resolved at compile time and is a no-op where there is no need to trace.

Handled static constructors and static members for generic types.

For the concerned generics, static constructors are called at every construction (and a flag make sure that we call the init only one time).
The current implementation is limited, it might create link errors if several assemblies using the generic with static constructors are compiled in different obj files. This can be improved later as needed.
Currently static members are traced when we are tracing each instance (that mean they can be traced several times). This will be optimized over time.
Accessing directly static members of a generic type may not return a correct result if a corresponding generic instance has not been created earlier (static constructor is called at instance creation).
Beside adding a check before each static member access I don't think there is an easy fix.

Anonymous methods are now supported!

There was more work than expected as I ended up having to generate what the C# compiler does. Pretty nice design though, very transparent for the user. Lot of work for the compiler ;)
Expect some issues if the declaring type is generic as I didn't test that yet. Should be easy to fix though.

Re-enabled Mono's unit tests.

55 unit tests have been disabled on around 230 unit-tests. The reason is because the features are not supported yet:
Unit-tests using things like: Reflection, Multi-threading, exception on divide by zero, attributes, CodeGen, StructLayout, Asynchronous delegates, __arglist, DateTime implementation, support for nan.
All these features are already documented as not supported or in the to do list...