If you had to expose functionality externally as a DLL but only a subset of functionality (meaning you can't provide a core DLL as it would expose everything) how is best to do this?
At the moment I can't really see any way of doing it that doesn't involve recreating the parts of the core library in a seperate DLL.
You could use internal along with Friend Assemblies. Your API can be a friend of the core library allowing access to internal members.
See here for more details - http://msdn.microsoft.com/en-us/library/0tke9fxk(v=vs.90).aspx
This would allow you to keep your core objects internalised whilst allowing the API access to them.
Note that you will STILL need to supply the core library. There's no way around this unless you use something to merge the .NET assemblies or you compile the code into your API library.
However I think this is a bad idea and you should keep such entities separate. I don't see why there is an issue shipping more than one library thesedays.
FYI - ILMerge will let you merge .NET assemblies, you can get it from here - http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
Surely by just creating a new project that wraps the core DLL, exposing only the methods you want exposed, each of which is acting more or less as a "pass-through" to the "Same" method in the core?
So if you core is called Core :)
it might have:
public int Foo()
{
//blah
}
public int Bar()
{
/blah
}
and if you want to only expose Foo, then you create a new project which references Core, and looks like this:
using Core;
public class MyApi
{
private Core _coreInstance.... //some way of reaching Core, in other words
public int Foo()
{
return _coreInstance.Foo();
}
}
An advantage of creating a separate assembly here is that you are then treating your core functionality as one concept, and the exposure of it publicly (to a particular purpose or audience) as another. You may very well want to expose "publicly" different functionality at a later stage, but to a different audience - you now have 2 different public APIs required: therefore any notion of what was "public" in your core assembly is now potentially ambiguous.
I think it depends on the aims you follow in hiding the core libraries.
If you don't want to allow your customers to call the code, for example if that may break usage scenarios of your libraries, or may cause undesirable behavior, or whatever to prevent CALLING the code, you can make the protected classes internal, and use InternalsVisibleToAttribute to include the Facade assembly. I would even use one more build configuration if I still needed core classes to be visible in my applications:
#if PUBLIC_BUILD
internal
#else
public
#endif
class ProtectedCoreClass
But of course if you have too many classes, some script should be prepared to change the existing classes, and Visual Studio's new class template should be modified.
But another case is if you want to prevent the source code from being WATCHED by your customers in order to hide some super unique algorithms or something. Then you should look into some code obfuscator. But there is absolutely no way to 100% guarantee the code from being decompiled and analyzed. It's only about the price crackers or competitors pay for it.
But if HIDING the source code is still extremly important, you should probably just host your code on your servers (to make sure the code is physically inaccessible) or in the cloud, and provide a WCF or a web service your exposing assembly will call.
Related
I am currently working with a piece of software known as Kofax TotalAgility or KTA for short.
This is Business Process Automation Software, which I have the "pleasure" of expanding with custom .net libraries.
I have been creating a MS Graph library to perform actions with the MS Graph API. The API works great and I am quite pleased with how it turned out.
However due to the way KTA is accessing methods in classes I have used "Data classes" (dont know if that is the right word) to use as input parameters for my methods. To be clear these methods have no functionality other than to store data for methods to use, the reason I am doing this, is because of the way it is structured in the KTA class inspector (I am assuming that KTA uses the IL Code from my library to create a list of classes and methods).
This is what I am expecting the user is shown when they are using my methods. As you can see by using classes as input parameters I get this nice hierarchical structure.
By using classes as input parameters another issue occurs which is that my "Data Classes" are show in the list of classes, which produces alot of unnecessary clutter.
Is there a way to hide these classes from the inspector? I get that it might be an internal KTA issue, which of course would mean I am not asking in the right place, and it is an internal Kofax issue.
However if there is some C# or .NET way of doing this, that would be preferable.
There are a number of different terms for the data/parameter classes that you mention, such as DTO (data transfer objects), POCO (plain old C# objects), or the one that you can see in the KTA product dlls: model classes.
There is not a direct way to hide public classes from KTA. However, when you use the KTA API via the TotalAgility.Sdk.dll, you notice that you don’t see all of the parameter classes mixed in with the list of the classes that hold the SDK functions. The reason is just that these objects are in a separate referenced assembly: Agility.Sdk.Model.dll. When you are configuring a .NET activity/action in KTA, it will only list the classes directly in the assembly that you specify, not referenced assemblies.
If you are using local assembly references in KTA, then this should work because you can just have your referenced assembly in the same folder as your main dll. However if you are ILMerging into a single dll to can add it to the .NET assembly store, then this approach won’t work.
When ILMerged together, the best you can do is to have your parameter classes grouped in a namespace that helps make it clear. What I do is have a main project with just one class that acts as a wrapper for any functions I want to expose. Then use ILMerge with the internalize option, which changes visibility to internal for any types not in the primary assembly. To allow the model classes to still be public, I keep them in a specific namespace and add that namespace to the exclude list for the internalize command. See Internalizing Assemblies with ILMerge for more detail.
Keep in mind that anyone seeing this list is configuring a function call with your dll. Even if they are not a skilled developer, they should at least have some competence for this type of task (hopefully). So even if the list shows a bunch of model classes, it shouldn’t be too hard to follow instructions if you tell them which class is to be used.
I have a Visual Studio Solution with two Web API projects and some shared or common projects.
WebAPI_1 (Big API)
WebAPI_2 (Very small API)
Data Respository
SecurityRepository.cs
Data Interface
ISecurityRepository.cs
Services
SecurityService.cs
Utility
WebAPI_2 project will use some methods from SecurityService.cs but only 5 from almost 50.
SecurityService.cs inside calls the methods using Dependency Injection from ISecurityRepository
Because when referencing a project will expose the complete DLL, is there a way that WebAPI_2 only sees the 5 methods that is going to use but there is no way to see the other 45 methods?
Also because Dependency Injection is used I was thinking maybe on creating other Interface with only the methods that WebAPI_2 SecurityService is going to use. But again the problem is that the whole Data.Interface project will be referenced.
I don't want to end having 2 projects of each just because of this.
Update: Don't know if InternalsVisibleTo could be used in this scenario but at the method level.
If you have source code for each of the API's, group them into a single assembly, marking everything as internal, and create a public API to expose it to external consumers.
I recommend using a Dot Net Obfuscation tool. C# sources are too easy to reverse engineer. If theft is an issue, program in C or C++ and expose a managed wrapper to C#. Beyond that, use a hardware encryption device to run/decrypt the program on the fly.
Sorry if I am not clear enough, I've had a hard time writing this question.
I downloaded an open source software. I would like to expand the functionalities so I would like to create modules that encapsulates the functionality these modules would be .dll files.
I would like to have one completely independent from another: if I set a key to true in the config file and if the DLL is present on the folder, the plugin should be loaded.
The problem is: how can I make the call for the plugin dynamically (only call of the plugin is applied)?
If I reference the plugin classes directly, I would have to reference the plugin dll, but I want to be able to run the core software without the plugin. Is there any design pattern or other mechanism that would allow me to load and use the DLL only if the plugin is applied and still be possible to run the core software without the plugin?
There are various ways to achieve this and I will describe one simple solution here.
Make a common interface that each plugin must implement in order to be integrated with core application. Here is an example:
// Interface which plugins must implement
public interface IPlugin
{
void DoSomething(int Data);
}
// Custom plugin which implements interface
public class Plugin : IPlugin
{
public void DoSomething(int Data)
{
// Do something
}
}
To actually load your plugin from dll, you will need to use reflection, for example:
// Load plugin dll and create plugin instance
var a = Assembly.LoadFrom("MyCustomPlugin.dll");
var t = a.GetType("MyCustomPlugin.Plugin");
var p = (IPlugin)Activator.CreateInstance(t);
// Use plugin instance later
p.DoSomething(123);
You can use some kind of naming convention for your plugin assemblies and classes
so that you can load them easily.
You can use MEF.
The Managed Extensibility Framework (MEF) is a composition layer for
.NET that improves the flexibility, maintainability and testability of
large applications. MEF can be used for third-party plugin
extensibility, or it can bring the benefits of a loosely-coupled
plugin-like architecture to regular applications.
Here is programming guide.
Plugins or DLLs in .NET jargon are called assemblies. Check out the Assemply.Load method, and also this guide in msdn.
The System.Reflection namespace provides many tools that will help you with this scenario.
You can
inspect assemblies (DLL files) to examine the objects inside them,
find the types that you are looking for (specific classes, classes which implement specific interfaces, etc)
create new instances of those classes, and
invoke methods and access properties of those classes.
Typically you would write a class in the extension which does some work, create a method (e.g. DoWork()), and then invoke that method dynamically.
The MEF mentioned in this question does exactly this, just with a lot more framework.
Well, I have a project, and by the moment I am using .NET 4.0, because I would like that this application is compatible with windows XP, because EF 5.0 is only for windows 7 and upper.
However, I would like to implement some parts of the application with the features of .NET 4.5, such as EF 5.0.
So for my database access I have a reposotry class that now use EF 4.0, this is a independent dll, so I can create other repository dll that use EF 5, and in my project import both dlls, then I can instantiate the correct repository according to the version of EF 5.0 that I can use. This is a paramater in the config file. is this the best way?
I ask this because I don't know where I must declare my interface. because my repository classes need to implement this interface, but then this tie my dlls to my application, but I need to use this repositories in two different applications, so I want to implement once, and use in many applications. I want independent dlls, because now are two applications, but in the future, can be more.
The reason to want to use an interface in the application that uses the repositories is because I would like to instantiate at runtime the correct repository, according to the config file settings. So in the fututre I can implement new repositories and there is no needed to change the code.
EDIT1: I read about multi targeting, but if in my project I use features for example of .NET 4.0 and I want to complie for 3.5, I get an error because this feature does not exist in 3.5. That's correct. Then the only way is to mantain two different projects? It would be a double work.
Thanks.
Daimroc.
So for my database access I have a reposotry class that now use EF
4.0, this is a independent dll, so I can create other repository dll that use EF 5, and in my project import both dlls, then I can
instantiate the correct repository according to the version of EF 5.0
that I can use. This is a paramater in the config file. is this the
best way?
You can go this route and I don't really see an issue with it unless you think that this could cause maintenance/development headaches in the future. There are a couple of other things that you can look into doing. I think both are completely valid and probably just personal opinion/preference.
Modules You can go a modular route where your repository DLLs are potentially loaded dynamically. Look into Microsoft's Unity library. This should allow you to create an IModule in each of your repository DLLs that will set up your application as needed. Then just create a UnityBootstrapper class to tell it how to find your modules (manually add them, look in a directory, etc.). This should allow you to hot swap your repository DLLs and not have to worry about setting a config file if you don't want to.
Preprocessor Directives With preprocessor directives you get to define how your code will compile. Depending on how you have your classes structured this may be something fairly simple to set up or a complete nightmare that makes you want to abstract and refactor your classes. This question: Detect target framework version at compile time has an answer for handling different compile results depending on the target framework. Personally though, I like the modular route.
I ask this because I don't know where I must declare my interface.
because my repository classes need to implement this interface, but
then this tie my dlls to my application, but I need to use this
repositories in two different applications, so I want to implement
once, and use in many applications. I want independent dlls, because
now are two applications, but in the future, can be more.
The reason to want to use an interface in the application that uses
the repositories is because I would like to instantiate at runtime the
correct repository, according to the config file settings. So in the
fututre I can implement new repositories and there is no needed to
change the code.
Sounds like you need to create another library that is used to communicate between your UI and your Repository libraries. This can be a little tricky and overwhelming to set up just right. Basically you want your gateway DLL to house the interfaces and business objects. Your Application would reference this DLL and this DLL would reference your repositories.
Depending on your needs you may actually need to set up another intermediary DLL that would actually just house your interfaces and most basic utility classes. This would allow you to have your EF objects implement the same interface that your application is using without the need for your gateway DLL having to map your business objects and EF objects back and forth.
EDIT1: I read about multi targeting, but if in my project I use
features for example of .NET 4.0 and I want to complie for 3.5, I get
an error because this feature does not exist in 3.5. That's correct.
Then the only way is to mantain two different projects? It would be a
double work.
I believe you can get around this by using the Preprocessor Directives I mentioned above. Below is just an example of making a method handle work differently depending on if the framework is .NET 2.0; it's just an example and not tested. The DefineConstants will need to be set up, but this should allow you to handle 1 project for multiple framework targets while also being able to use newer .NET features as they are released.
public Person FindPersonByName(List<Person> people, string name)
{
#if DOTNET_20
foreach(Person person in people)
{
if (person.Name == name)
return person;
}
return null;
#else
return people.FirstOrDefault(p => p.Name == name);
#endif
}
I hope this was helpful and the best of luck in finding the right solution.
I am designing a WPF application that uses a DLL with maybe 40 public classes. I need these to be public for a variety of reasons including ease of data binding and obfuscation. I would like to allow other people to use only a portion of these classes as an API for my software.
I thought I would create the main library (core.dll) and an API library (coreAPI.dll) with the API DLL to be referenced in a new project. Is there a way to allow coreAPI.dll to expose only a few of the classes that exist in core.dll? It's not so much a security issue as I primarily want to simply hide some of the unwanted classes from the Visual Studio Intellisense.
Again, internal classes for the ones I want to hide is not really an option because I need to data bind some of these classes in WPF and for that, they must be public. Are there any other ways of doing this?
As Damien already mentioned, if the only thing you'd like to do is to hide from Intellisense you can add the following attribute to your hidden classes:
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
If the primary issue is Intellisense, then moving these classes into a separate namespace would surely do the trick?
Of course, you could split the classes into two separate assemblies. You may have some issues there with having to expose more classes than you want (because they now live in separate assemblies), which might be resolvable using the InternalsVisibleTo attribute