I have an application, written in C#, which needs some functionality from VB.NET (better said, something valid in CIL but not provided in C#).
So I have an executable and a library file.
Problem:
It has to be published in one file and may not be split to different assemblies!
But:
It's a WPF application, ILMerge will not work.
What could I do?
Is it possible to generate (performant) IL on the fly?
See this question (and various answers) for merging a WPF exe and library dll together:
Merging dlls into a single .exe with wpf
See this answer, for a C# version of Exception Filters (may not be applicable in your case, kept here for future reference):
More Elegant Exception Handling Than Multiple Catch Blocks?
You can have one assembly, but with multiple modules compiled in different languages. You would set up three projects:
Now, you can't use Visual Studio to build this (AFAIK, but you might be able to fiddle with the project files/MSBUILD tasks to do this), but you would use the command-line compilers to create netmodules.
Using csc.exe (for C#) you would use the /target:module command-line parameter, while with vbc.exe (for VB.NET) you would also use the /target:module command-line parameter.
Then, when building your EXE project, you would use the command-line compiler (depending on the language) and use the /addmodule:<module> (assuming the EXE project is in C#) or the /addmodule:<module> (assuming the EXE project is in VB.NET) to point to the modules that you specified to include in the EXE output assembly.
You also have the option of compiling everything into modules, and using the Assembly Linker (Al.exe) to produce an output assembly.
If the above option doesn't appeal to you, then another option is to pick one language and use that.
If you use VB.NET, then you will have exception filters (which you indicated is the piece you needed, which is a language feature, not exposed through the framework).
If you use C#, you don't have exception filters, but you can emulate them as indicated by George Duckett's answer.
I suggest that you still create two assemblies during the build but then embed one into the other as a resource. This way, you can call Assembly.Load() and load that secondary assembly.
using (var stream = Assembly.GetExecutingAssembly(). GetManifestResourceStream(resourceName)) { Byte[] assemblyData = new Byte[stream.Length]; stream.Read(assemblyData, 0, assemblyData.Length); return Assembly.Load(assemblyData); } See http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx for details.
