Consider the following situation:
I have developed a DLL file DCore. Afterwards I developed a DLL file DCustomer which uses methods from DCore. Now I want to distribute DCustomer as DLL for a customer and make sure to hide all functionalities of DCore, so that the customer can only access the functionalities of DCustomer.
How can I hide the functionalities of DCore when creating the DLL file DCustomer?
There is nothing much you can do about it.
But do check out StrongNameIdentityPermissionAttribute
I would also request you to check out this Thread
Related
I have written two addins , 1 for excel and 1 for word. However these addins have a lot of duplicates: Database handling, file handling,array handling which I would like to update 1 place instead of two.
We do have access to sharepoint, and could get access to visual studio. The thing is that people like to use file explorer and find the correct word or excel file, then open it then press a button inside the application which then should do things with the active document.
This is why we haven't written it as a .Net application yet, because that requires that people browse for the file inside the .NET application uless I am mistaken.
Is it possible to make an Addin which works both excel and word, or a dll? AnAnother important thing is that it should be easy to roll out a new version to the user, like stored on a network drive or similar.
Yes it is possible
The Hard Way
You can create a .Net DLL and call it from VBA. In visual studio a lot of people use Unmannaged Exports by Robert Giesecke to create DLLs that don't need to be registered (that way the DLL can be shipped with your document, and as long as it can be found you can use it).
Alternatively you might be able to do it manually as shown here by Hans Passant.
The Easy Way
Once the DLL is created you can declare it in a VBA module the same way you declare any other DLL for Late Binding and then call it from your code.
OR if you're happy to create the DLL and add it as a reference (possibly less portable) you can make it COM visible and register it for COM Interop in Visual Studio; this is probably the easiest way to go because you can then use Early Binding.
This is a walk through that might help: http://www.geeksengine.com/article/create-dll.html
But if you want to store the DLL on a network drive, well it might be that you really want to look at doing it the 'hard way', in which case look here: https://stackoverflow.com/a/5934745/3451115 and here: https://msdn.microsoft.com/en-us/library/bb687915.aspx
What ways have people found/used to add functionality to a .NET/C# app without recompiling?
The methodology that comes to mind for me is having code that looks for a file to read, parses that file, and then dynamically creates controls and their event handlers, etc., based on what is contained in the file (possibly an xml file).
Or would dynamically loading .DLLs be considered "not recompiling"?
Any ideas/"war stories"?
All you need - MEF - Managed Extensibility Framework
For fairly simple cases with well defined behaviors:
Define an interface for you plugin.
Implement the interface in dlls.
Load dlls with Assembly.LoadFrom.
I'd add a GUID to each dll too so you can tell them apart.
Look at how ASP.Net does it - you can add ASPX/ASPX.cs file while site is running. Short version: ASP.Net listens for file changes and compiles new files into new assemblies, than loads into existing AppDomain to use for rendering new pages.
I've got a problem which I hope you can help me with.
I created ASP.NET 4.0 web application. I've also got .cpp file generated in some other app. This .cpp file contains functions, which always returns the same number of variables and which always takes the same number of parameters.
What I need to do is being able to use this functions in my web application.
But what is real problem is that I need to be able to replace this functions while running app. What I mean is administrator should be able to login, upload new cpp file, which will replace old functions with new ones. New ones will have the same names, parameters and result number, but will make calculations in a different way.
Is there any way this can be achieved?
Thanks for any help!
MattheW
Precompile the cpp code into dlls and let admin upload dll. Reference dll's from c# app using [DllImport("")] directive.
C++ will need to be compiled in some way or another. You can use a compiled dll written in C++ in your ASP.NET application but the code will still need to be compiled for ASP to be able to use it.
The compiled DLL can then be loaded and unloaded to accommodate changes to the function. You could perhaps even make the ASP.NET server compile the file somehow, but the code still needs to be compileable to a DLL to make it executable.
You need to expose the C++ code via another dll.
The first choice is pinvoke. See:
How to set up a C++ function so that it can be used by p/invoke?
It's also covered here:
http://msdn.microsoft.com/en-us/library/aa446538.aspx
Technically you could also expose via COM or write in managed C++ but those are both overkill if you're just trying to expose a few C++ functions.
I'm looking into registering a directshow filter at runtime and probably need to use reflection to do this and then call regsvr32 somehow on binary data. Not sure if this is possible, sounds tricky. Basically I have a dll file that is a filter and I added it to the solution as an embedded resource but after this I'm stuck... not sure how to go about registering it. Does anybody have any insight? Is this possible to do or do I have to have the file existent to register it? Thanks.
Cheers.
Are you sure you need to register it? You only need to do it if it is to participate in Intelligent Connect. Otherwise you might just LoadLibrary the DLL and create an instance of the filter via DllGetClassObject bypassing COM instantiation. Good news you don't have to be administrator with elevated privileges to do this, as opposed to registering the filter DLL.
Then see also:
Embedding unmanaged dll into a managed C# dll
How can a C++ windows dll be merged into a C# application exe?
does somebody know how can I embedd an exe file into a dll ?
I have a tool which is an exe file that I call from c# code.
The thing is that I want to have 1 dll containing this tool (exe file) and the dll containg my c# code.
Is it possible to embedd this exe file within the resources?
Thx in advance
Sure it is. You can add any file as RC_DATA in application as resource. But I believe you will need to extract it to disk first before calling it!
Which IDE/Language you are using?
[EDIT]
Sorry! you did mention that you are using C#.
Add a resource file to you application (right click application in IDE and select "Add new item".
Use the toolbar in resource editor to add an existing file.
Then extract the exe whenever required by calling code something like:
System.IO.File.WriteAllBytes (#"C:\MyEXE\", Resource1.MyEXE);
It's worth baring in mind that your uses may not be too happy about you doing this. Embedding an executable that they've got no control over into a DLL that you'll extract and run will probably make people worry about the running a Trojan on their machine.
It's better to leave the .EXE in the filesystem and be transparent about what your application is doing.
You can load an Assembly from a byte[]. This can be obtained via the ManifestResourceStream of an embedded resource.
An alternative may be to not embed the .exe itself, but rather include its functionality in the dll, and use rundll32[1] to execute it.
On a side note, remember that when you pull a file from your resources to disk and then execute code on it, you may trigger Windows Data Execution Prevention - basically, Windows tries to automatically detect if something is supposed to be code or data, and if it looks like data (which a resource would), then it will prevent that data from being executed as code.
This becomes a particularly sticky issue if your .NET assembly is going to be used over a network instead of from a local drive - there are all sorts of .NET security configurations that might prevent this from working correctly.
Another option, and not knowing the details of your project, take this with a grain of salt: add a .exe.readme file to your install that describes to any curious users or IT people why there is an executable they weren't expecting in the installation directory :)