Plugin program could be coded with C# 2.0 or 3.0, not 4.0, so I want to call a dll coded with C# 4.0 in the plugin dll.
I have installed both frameworks.
How can I do that? Thanks.
I tried reference and COM, both are fail.
Possibly, you need create new AppDomain and download your plugin into it (please note that you need to subscribe to the events of reference resolution). Another way is another process and interprocess communication.
The CLR is not forward compatible.
Have a look at ths link
The DLL might expose an interface which uses 3.0/3.5/4.0 features, so the caller needs to know the features to use them.
Only way would be to wrap it using unsafe code or a real COM registration as an interface between an intermediary dll and the actual 4.0 dll, but I agree that providing a clean webservices via WCF is the better solution if you want to have 2.0 callers for a 4.0 dll.
Also note, that you do not need to install CLR 2.0 seperately - it will be installed implicitly when installing 4.0.
Related
I have begun the process of migrating one of our many ServiceStack services from .Net Framework to .Net core. Most of the migration has been relatively smooth, but I have run into a brick wall with Service Models. This service is dependent on using other ServiceStack services that are still on version 4.0. When I attempt to use Service Models from those services in the new project I get an error saying that the IReturn<> interface wants the version 4.0 assembly specifically, and does not want the 5.0 version of ServiceStack.Interfaces. Downgrading just ServiceStack.Interfaces causes a similar error, but the inverse where everything else that depends on that assembly wants version 5.0. Is there a way to upgrade one project without upgrading every project? I think we all know that real systems need a transition period, and that there's just no way to migrate every service simultaneously.
Please read the existing links from this answer:
https://stackoverflow.com/a/51252374/85785
TL;DR you can’t share the same .dll, you either need to multi-target or decouple the binary dependency by using C# Add ServiceStack Reference.
Other solutions is having old Framework projects Reference the old compiled ServiceModell.dll (alternative to multi targeting) or just copy the source code of the DTOs you need (alternative to C# Add ServiceStack Reference).
I need to consume a library that doesn't yet have CoreCLR support (RabbitMQ.Client, to be specific). Is it possible to utilize a mono-based port of that library on a Linux system from inside a CoreCLR executable? If so, how is that achieved?
It is impossible at binary level (unless using a proper PCL profile). .NET Core has a different approach to arrange classes in assemblies, so some assemblies on desktop .NET Framework are broken into smaller assemblies, and types are moved. A desktop targeting assembly (from .NET or Mono) won't work on .NET Core due to such changes.
But it is obviously possible at source code level, as there was an attempt to port Mono's WinForms to .NET Core,
http://forums.dotnetfoundation.org/t/anyone-porting-winforms-mono-to-net-core/898/4
Once a new .NET Core library project is created, the source files should be able to be carried over (with some modification or even none).
However, .NET Core has been evolving too fast, and that attempt might be now out of date. Anyone would like to explore in this area can follow that example and try once again. Good luck.
I am wanting to port a C# Mobile App for Windows 8 tablets using Xamarin. One of the issues we foresee is the use of MEF. Does Xamarin.iOS support MEF?
It depends on what you mean by MEF support. Using MEF assemblies is possible using Xamarin.iOS. What's not possible (iOS restriction) is dynamically loading code in your application (e.g. plugins).
You might be able to use MEF while ensuring there's not dynamic code being loaded, i.e. that everything is statically referenced and built inside a single binary executable (e.g. by ensuring every plugin is built-in).
Depending on your application that could prove useful (no, or less, need to modify your existing application) or not (if your app can't load/be built with all plugins). In the later case your problem is with iOS itself (not Xamarin).
I have an multiple assembly C# Excel addin which passes embedded interop types across assembly boundaries. When I run this in an Excel process configured to use .NET 3.5, everything is OK. When I run this in an Excel process configured to use .NET 4.0, only controls with application logic defined in the addin assembly itself load. I think I understand why, since the handling of embedded interop types changed significantly in .NET 4.0, so that they must not cross assembly boundaries. What confuses me is that I thought in .NET 4.0 multiple instances of the CLR could be hosted in a single Windows process. If my addin targets .NET 3.5, why can't it just run in a .NET 3.5 CLR instance owned by Excel? Why is Excel trying to run my addin in .NET 4.0? It's not really an option to rewrite the addin, but it needs to install for a client who also use .NET 4.0 addins, so it's not OK to play with registry keys or the Excel.exe.config files... Any help will be REALLY appreciated!
The answer to the question in your title is 'yes'. The .NET runtime version 2.0 (which is the runtime version used by the .NET Framework 2.0, 3.0 and 3.5) can run side-by side in a process with the .NET runtime version 4.0 (which is the version number that will also be used by the upgraded .NET Framework 4.5).
However, the VSTO case is not so simple, since there is interaction between Excel and the VSTO runtime to decide what to load. VSTO 4 basically includes separate versions of the Office extensions targeting .NET 3.5 (under the .NET 2.0 runtime) and .NET 4.0. Depending on which version of the VSTO 4 office extensions you target, you uses classes (compatible with older VSTO) or mainly interfaces, so the VSTO API design and your code is a bit different too, depending on which version of the VSTO 4 office extensions you use. Then deployment and loading of your VSTO add-in depends on which version of the VSTO Office extensions you target.
So the version of the .NET runtime that your VSTO 4 add-in loads in is linked to how you made the add-in. Read more here: http://msdn.microsoft.com/en-us/library/bb608603(v=vs.100).aspx and http://msdn.microsoft.com/en-us/library/ee712596.aspx.
If you have other COM components, it could be that the COM components are activated in a different version of the runtime (say in the 2.0 runtime) and are then not accessible from the 4.0-runtime based add-in. The way COM interop type changed in .NET 4.0 would typically make things work better, since the runtime now correctly identifies types defined from different assemblies as 'the same' based on GUIDs etc.
To make life easier, I can also suggest Excel-DNA (which I develop). It is a free and easy add-in library for making full-featured Excel add-ins in .NET, without using VSTO. Excel-DNA allows you to target any version of Excel, and any 2.0+ version of .NET.
I'm not familiar with developing excel addins but yes you can do that.
However using a different versions of clr in the same process is to done automatically.
You can read the details here.
I am trying to port an existing c# .net application that is using MEF extensively to MonoTouch and MonoDroid. Does MonoTouch and MonoDroid support MEF?
Try using PocketMEF.
It is a subset of MEF that can run on PocketPC, WindowsCE, etc.
You will have to create a MonoTouch project from the source, because I would think there would be some minor changes to make it run in MonoTouch.
All the attributes and classes are named the same as standard MEF, you should only have to change a reference and a using statement with #if iPhone to get it working.
According to the list of MonoTouch assemblies and Monodroid assemblies, the MEF assembly (System.ComponentModel.Composition.dll) is not included.
It might still be possible to compile the MEF sources for these platforms, but this would probably require modifications to eliminate unavailable dependencies.