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
Related
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 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
I have to use some API in my project and for that my boss asked me to create lib for that API. Its .Net project and may be in future it may have Android app. But for now he wants me to create lib in c# by hitting on API. Can you suggest me should I start with portable Class lib or class library?
This is the API for which i have create lib
http://api.synapsepay.com/v2.0/docs/user-resources
Portable class library is the best choice. PCL is for creating code that can be used on multiple platforms in the .NET family. PCL may be useful later if you're planning on using something like Xamarin to publish for android, but isn't useful for anything that doesn't pertain to .NET right on creation.
Portable class library if you want features of that library to work cross platform and to save you time from re-developing your library in the future for cross platform use.
I don't think you should go to PCL just for now. Due to Microsoft's poor design, a PCL profile provides much less APIs to consume and you often find things missing.
Don't give yourself extra pain for Android which you won't support in a minute. When the time comes, you can see if other way to share code is better.
For my own projects, there are library projects for different platforms which share the same files. That still works better than PCL.
I've created a code library for use with Umbraco, as you'd expect it does all of the common tasks that I use over and over. I work for a digital agency and we support sites that are built from Umbraco versions (4.5.x onwards).
To date we've always complied the library against the same dlls as we're using for the current project, but this isn't great and we've ended up with lots of different branches, one for each version. Having this many branches is a nightmare and I'm trying to find a solution that has one project that can be used to all versions.
I'm just wondering if anyone can think of or knows a way of having doing this or has any experience in this?
If you code purely to the INode interface then you should be able to create your library independent of the version. DynamicNode and DynamicMedia both implement INode.
I have got a dll from another program on my computer.
According to its name it could have the functionality that I need for my own c# project.
It seems to be also made with c#.
Is it possible to find out the functions in it and use them?
If it is a C# DLL then you can add a reference and use it. If it is a native DLL then you'd need to do some reverse engineering.
However, what you are describing is not the normal way to do about developing software. To write decent software you need to have good documentation for the libraries that you use. Trying to guess how a library is meant to be called is a recipe for disaster. Development should be based on a solid and deep understanding of the tools you are using.
Visual Studio provides the Object Browser if you want insight about a DLL (for those written in .NET involving IL).
screenshot of object browser http://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-65-29/4774.wmob04.jpg
Borrowed from this msdn blog
However, if you need more control or want the ability to not only include the library but view the source (in most instances) and step through it (debugging), I suggest grabbing .NET Reflector.
You can just reference the dll you want in your project and use Object Browser to see what Methods etc you can access.
Step 1: Add reference
Step 2: Choose dll
Step 3: View in Object Browser
Step 4: Browse Library
Step 5: Find what you need
Happy Coding :)
Absolutely! If you can add it as a reference by right-clicking your project references, clicking add reference, and then browsing to it, it should be compatible with the version of .NET that you are using. At that point, try to instantiate it and see if you can go to definition on the instantiation. Crude but an effective way to get used to using external dlls.
If it really is a C# DLL, then you can add it as a reference to your project and then use the Object Browser to see what namespaces and classes it contains.