I am writing a Library using C# and my library uses a third party .NET library. When I roll out my Library I have to include the third-party library as well along with my library. However I want to prevent users of my library (client code) from directly using the third-party library. Is there any way to enforce that at compile time or run time?
If there are no legal issues with doing so, you can use ILMerge to merge the 3rd party library into your own one.
You have the option to make public classes from the 3rd party library internal. This way, clients of your code will not be able to access functionality from the 3rd party library (unless they do some kind of hack. For example, I am not sure if someone can use an internal class using some kind of Reflection code).
Take a look at this article
Related
Sorry if this has been asked before but I'm struggling to work out how to phrase my question.
Essentially, I am developing a shared library that must depend on third-party vendor code - I want to ship this shared library through our internal NuGet server. However, the exact versions of the third-party library can vary based on the client's install.
What I want to do is provide a way for consumers of my library to:
Reference my library via NuGet
Select the exact version of the third-party library my library should depend on
Either:
Not have to provide much binding code to do this, or
Be able to reference another library I provide that can handle the binding code
Is there a specific name for what I am trying to do, and does anyone know how I can do it?
Thanks in advance
I want to write a library that leverages functionality from e.g. JSON .NET. Let's say I use version 8.0 of JSON .NET. When I distribute my library, anyone who uses it will have to use the same version of JSON .NET, and it will conflict with any versions they are already using.
I could isolate the serialization part of my library into a separate NuGet package, but that would still be dependent on the particular version.
How can I build my library in such a way that it provides such serialization capabilities out of the box, and yet does not restrict the client code in terms of third party packages? Are there any existing patterns for this kind of thing?
Actually, your assumption is not exactly correct. Other versions of dependencies can be used. In .NET, we use assembly unification to accomplish this. Essentially, the end user's config file can be written to say, "when the code needs version 8.0, it's okay to use 9.0". And most of the time, newer code is written to be reverse compatible.
Ultimately, you can't stress out about it. Comes with the territory.
I have IronPython right now working with PyCharm. Is it possible to import classes from a 3rd party .NET DLL that I have written and get code completion with it?
Currently I'm creating a .NET application where users can upload their Python scripts and interact with the application. Basically I want to create a .NET library that users can import into their Python project and use classes from it with code completion.
Is this possible?
It looks like PyCharm handles Python C extensions by generating a "skeleton" module and using that for completion. The same approach would work for IronPython easily, thanks to .NET reflection, but I don't know if PyCharm supports that sort of extensibility.
I have a c# dll that needs to be called in Java.I see that there is a method using jni to call c++ dlls.How can I do it for a c# dll..Please help..I couldnt find any good material on this
From here:-
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET
Framework. It includes the following components:
A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries
Tools that enable Java and .NET interoperability
You can use Java Native Interface. Or you can create a COM assembly from the C# code and use J-Interop to invoke it.
If you have C# dll sources you need to use maybe the better way will be to translate it to Java using some tools like GrassHopper.
According to GrassHopper key feature explanation it can convert MSIL to Java bite code. So can use without sources of c# dll
Check this: http://www.javonet.com
If you look for quick and easy solution then Javonet should work fine for you. It is light counterpart of IKVM and J-Integra works also as native bridge.
All you have to do is:
add Javonet.jar do your project call
call Javonet.addReference("yourlib.dll")
use your .NET library like it was almost JAVA package
Sample:
NObject obj = Javonet.New("yourDotNetClass");
obj.invoke("YourMethod","arg1", 2);
The syntax is not strongly-typed and works like reflection but gives you fastest access to any custom .NET code, third-party libs or .NET framework as no changes are needed on .NET side. If you need it is also possible to implement custom strongly-typed wrappers.
I do recommend this bridge as in my opinion it is easiest to quickly get things done but also other native bridges are worth checking as this is best approach for such case.
I would avoid going into custom JNI or COM unless you have a lot of time and you just want to learn, if you need quick and reliable solution take one of third-party bridges.
I know how to create a COM DLL (a Class Library) in C#. Is it possible to create a COM Surrogate EXE using C#?
This would be a standalone server capable of launching and hosting COM objects, which would then be accessible to COM clients.
The default surrogate process for COM - the thing that hosts COM DLLs, aka the COM Surrogate - is dllhost.exe. It is possible to create a surrogate process in C++. This article explains how.
But those APIs are not exposed in wrappers as part of the base class library in the .NET Framework. If you want to write to write only managed code, you need something else.
I see a couple options.
The Visual Studio SDK, a free download that is intended for devs who want to extend Visual Studio. Within that SDK, there's a class lib that has such wrappers. In particular, look at the ISurrogate class.
BUT, the VS SDK license says that the SDK is ok to use only for products that extend or add value to Visual Studio. I am no lawyer, but that is my understanding of the license, which is pretty clear. These terms means the VS SDK would not be useful for general app building.
The one remaining question is, exactly how do you use the VS SDK technically to produce a COM Surrogate using only C# code? Again, here I don't know. I looked in the docs briefly for guides on using the ISurrogate wrapper, but found none.
Use the code in this article.
The article explores a bunch of different aspects around COM and .NET interop. Towards the end of the article it offers source code for building your own COM server in C#, complete with all the p/invoke calls to CoRegisterClassObject() and friends.
I wanted to make same thing and found excellent project example CSExeCOMServer on All-In-One Code Framework. It actually reconstructs normal COM server logic by means of .NET and native calls to Windows API. But it looks all still overcomplicated. I suppose there is no simple and fast way to expose .NET objects as COM in out-of-process server and it is not the architecture of choice.
One option, if you want an out-of-process COM component, is to host a dll in COM+ via serviced components. This only supports dll though, but you could write a shell exe (for standalone use) that simply defers to the dll.
Not quite as simple as VB, but it works.
I do remember somebody showing me a more direct way (no COM+), but I can't for the life of me remember what it was...