For reasons I can't explain here, I need to create a single dll file that can be used in .Net Framework applications. In that library, I use a 3rd party library that can not be (directly) used/imported by the end-user application. I use Fody/Costura to bundle the library into one dll file.
In my own library, I have a class that inherits from a class in the 3rd party library. I can use that class without problems in the application, but I get compile errors when I use properties of the base class. I can avoid these compile errors by creating a "proxy" in the child class.
Is there any way to make this work, without these proxy properties?
Related
I'm kind of new to Silverlight and I have a solution which has one web project (webApp) that provides remote services and two client applications (client-1 and client-2) that uses these services.
I have created a complex user control in client-1 that view/edit an object retrieved from webApp and I want to re-use this control in client-2.
The problem is, when you reference the service from the client apps, the types are "locally-typed". For example, MyClass defined in the webApp becomes client-1.MyClass in client-1 app. Using exactly the same object (reference) in client-2 app, it is now of type client-2.MyClass
If I create a library to host my control, I will have to add a reference to the web services and I will have a third type, lib.MyClass. We all know that client-1.MyClass, client-2.MyClass and lib.MyClass are all exactly the same class that was generated from web.MyClass but I can't find a way around this problem.
I'm currently looking at sharing the source code of the user control in each client application and having pre-processor defines in each project so I can do this in my user control code file:
#if CLIENT-1
using Client-1.WebAppServiceReference
#end if
#if CLIENT-2
using Client-2.WebAppServiceReference
#end if
Then the method that uses the type MyClass are using the correct "local-type" in each client app. But I'm having problem since there is no pre-processor functionality in the xaml and there is a reference to the application's namespace there that I need to be conditional.
There's got a be an easier way of re-using controls accross silverlight projects, no?? There is no way I'm going to have two copies of the source files for this control, on in each project!!
Thanks!
There are a couple of options that allow you to use shared entity classes across Silverlight projects/WCF service proxies.
Use an RIA class library
Use a portable class library
If you create your DataContract classes with either of the above, and then reference the library from both your WCF and Silverlight client projects, then the auto-generated code will use a reference to those shared classes (rather than the locally auto-generated classes). This should allow you to re-use your Silverlight UserControls between projects.
The difference between the two approaches is this. If you use the first approach (RIA project), then when you create files named "SomeEntityClass.shared.cs", the ".shared" tells Visual Studio to place a copy of the file in a mirror Silverlight project. The second approach (PCL) is a newer approach -- it allows you to create class libraries that are capable of targeting multiple platforms (.Net, Silverlight, Windows Phone, ...), with a reduced set of core .NET libraries.
I suggest you to dissociate the XAML and graphical stuff from any of Business logics and the like. MVVM is a very good pattern to follow.
After that, you can reference your UserControl from second project with the very useful functionality of Visual Studio "Add as Link"
Here how you can do it :
For the underlying business, you can make it available for both project, and linking these 2 with it.
Hope it helps
I wrote an application in C# and added a kind of API for it.
With this API you can write plugins as dll´s which underlie some interface rules.
I want to make it possible to open the dll file via OpenFileDialog and use its content.
My API is a managed library, so I just add a reference, but I want to use the dll without knowing the name of the dll file. Also the namespace is another each library.
How do I load a dll and run the code within it?
What you are describing is commonly termed a Plugin System. Googling for something like "Create Plugin system using C#" will probably give you lots of information such as the below:
http://www.codeproject.com/Articles/4691/Plugin-Architecture-using-C
The basic idea is:
Define an interface that your program implements to allow a plugin to get information from your program.
Define an interface that all plugins will implement, to allow your program to call the plugin's methods that will do something.
Put those interfaces in a separate dll that's referenced by your program and by any plugin dlls.
Provide some way of finding dlls with types implementing your plugin interface, e.g. your OpenFileDialog.
Load the dll and find types that implement your plugin interface (using reflection).
Instanciate those types using reflection.
Call the methods on those types via the interface, as appropriate.
Regarding managed/non-managed. A managed DLL is one that is built/coded using the .net managed runtime. This would be things coded in a .net language such as c#.
A non-managed dll is more or less anything coded in a different language.
What you referred to as a non-managed dll I would refer to as a dynamically loaded managed dll. I.e. it's still a managed dll (coded in a .net language), but isn't loaded until the program is already running.
You can load a managed assembly from a dll file with Assembly.LoadFrom Method (String) (See also Best Practices for Assembly Loading).
I would like to know how can I export dll functions because I have a program which requires function exporting in order to use them.
Can I accomplish this in c#?
PS: The program who's using the dll is not O.Source and I can't add the reference into it.
1 You can use MEF Framework - Based on Export, Import and Catalog
Link : http://msdn.microsoft.com/en-us/library/dd460648.aspx.
2 You can also expose on your network by using WCF
Link : http://msdn.microsoft.com/en-us/library/ms735119(v=vs.90).aspx
Nota : You have another possibilities, it depends on your choice and technical constraints
If the other application is a .NET application, it can add a reference to your assembly (DLL), and use any public type defined within the assembly. This gives it full access to your code.
If you need a native API for use with your C# code, then this becomes more difficult. There are a few options:
Use COM. You can mark types as ComVisible, and register the assembly. This allows your code to be accessed via COM.
Use C++/CLI to build a native wrapper around your managed types. This would require a separate assembly (DLL) that provides the native exports, and uses the managed types internally.
The best option here really depends on how the "other application" needs to gain access to your code. If it's not a .NET application, COM is typically the simplest (and often nicest) option.
Probably, the closest option to your requirement would be using Unmanaged Exports.
For other options, see here and here.
I currently have a C# project which uses plugins and has a fairly common approach to plugin handling: an IPlugin interface is stored in a dll which is linked in a tranditional dynamic way. The host app looks for class libraries exporting classes exposing this interface and loads them via reflection at run time.
The dll containing the interface also contains helper classes, for updating plugins, providing abstract base classes and so on.
My question is, what does it take to break the interface between my host and plugin assemblies? In other words, if I compile and distribute the host app and then distribute plugins that have been linked with a later version of the plugin dll (in which helper classes have changed, but IPlugin is defined in exactly the same way), will the host still pick up the plugins? How much of a change do I need to make to the plugin library before IPlugin is considered a different "type" by the reflection methods I am using?
If the assembly isn't loaded by a specific version than I would say the only breaking changes you will really encounter are when you change the interface contract. If you are just changing helper classes it shouldn't be a problem.
How should I divide source files into projects (within one solution) to
be able to use common classes in more relatively independent apps,
avoid lots of dlls needed (preferably all in one file for each application),
keep it fast?
There are working (data processing) classes, User controls, some utility classes and Forms of the application.
You can make a separate assembly by creating a class library, and use that library within other projects within your solution. Just put your reusable classes within a class library project, and add a project reference in your applications to that library.
Each time you separate out code into a separate (reusable) assembly, it does add one extra DLL (the class library project) as a requirement at runtime, but this is very minimal.
There are no real (significant) changes to performance when doing this. It is a very common practice.
You should make Class Library project(s) for each logical unit of classes, then add references to the libraries in each project that uses them.
For example, you could have a Common library that contains basic classes used by everything else, and perhaps a Controls library that contains user controls.
Each logical unit of classes can go in a namespace within the same library or in a separate library; you need to decide which.
It would be a good idea to drop the second requirement of avoiding lots of DLL's. If you put your common code into a single "common" DLL then you need to recompile every time any class is added or modified. This could then give you a terrible versioning problem that is worse than managing lots of DLL's.
You should group your common code, by the functionality they provide, into separate DLL's. So one for data access, one for user controls, one for each type of utility function, etc. Then if you have web service that accesses data you won't need to recompile the service when you add a new user control to a single DLL. Only those apps that depend on the change will need to be recompiled.
You could put the common classes into one assembly (say CommonUtils) and then use namespaces inside for the groupings to indicate how they are split