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.
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 have written a project on .NET 4 and am currently in the process of allowing it to run on Windows Phone as well. I am using HtmlAgilityPack, a well known library which allows Linq queries over HTML, and am only using the LoadHtml and Linq interfaces it provides.
Having converted the class libraries from .NET 4 to PCL (Portable Class Library) with support for .NET 4 and WP8, I cannot seem to use the HtmlAgilityPack library anymore. Is there a way to allow HtmlAgilityPack to function correctly under a PCL project or is there a variable alternative with a similar Linq interface that does work as intended?
EDIT: HtmlAgilityPack provides 9 different versions, none of which are compatible with PCL. None of them resolve dependencies from the references. For some versions, it may appear that it does but upon usage an error will be thrown with the usual 'cannot load, unresolved dependencies'.
EDIT #2 Since it easy to miss a small comment, I'll update this answer with the solution I came up with. I extracted what was needed for basic functionality and implemented the missing components to make everything work. The result is here https://github.com/Deathspike/HtmlAgilityPack-PCL
One option is to port the HTML Agility Pack source code to a PCL. You can run the PCL Compliance Analyzer over it to get an idea of how hard this will be.
Alternatively, use the abstraction pattern. Create a portable interface for the functionality you need (ie LoadHtml and Linq), and then implement that interface for each platform by calling into the HTML Agility Pack. Then your portable code can depend on the platform-specific implementation.
For more information, see this blog post: How to Make Portable Class Libraries Work for You
You've asked and answered your own question - haven't you?
The HtmlAgilityPack does not support use with Portable Class Libraries.
At best you'll need to look at porting/migrating the specific functionality you require in a way that will work on the platforms you are using.
Look at HtmlParserSharp, this is a C# port of the validator.nu HTML5 parser. The project should be very easy to build as a PCL library since it's more or less a straight C++ port and uses only the most basic of .NET framework classes, with a few updates to improve performance in C#.
While most the work I've done with HtmlParserSharp has been for CsQuery, which itself is a long way from being PCL compliant, there is no reason at all that HtmlParserSharp would't work perfectly well on it's own as a lean HTML parser for your purposes. The project includes an example of building a DOM based on an XmlElement, but the tree builder is an abstraction so you could easily change this to use your own tree node objects instead.
I have an assembly that provides an API and is used by some other assemblies. I need to verify that a newer version of API dll is still compatible with the older assemblies that were using the older version of API.
I've found a couple of questions that ask the same, but there are no answers that resolve my problem:
Tool to verify compatibility of a public APIs
Tool for backwards compatibility for the C#/.NET API
Suggested tools can only compare two assemblies and say if there are possible breaking changes in API, but not if the newest API really breaks the older assembly that uses it.
I'd like to find a tool or write a test that will be able to check whether each of the older dlls can work with my new API dll.
As for the changes in API more likely that I will only extend it, but even though it still can break the code in older assemblies. Some of the examples of such changes can be found here:
A definite guide to API-breaking changes in .NET
.NET: with respect to AssemblyVersion, what defines binary compatibility?
For now the only solution I see is to compile the source code of the older assemblies with the newest API, but I would like to do it only with assemblies and add them as part of my unit tests. Is there any better way I can handle that?
edit:
I'm looking for a tool that will be able to automate the process of verifying the backward compatibility between .net assemblies. (command line or with some api too)
What you want is to do a diff and generate a the list of breaking changes. Then you want to search if of your assemblies does use any of the broken APIs. You can do this with ApiChange tool to do the diff and to find any affected users of it.
To make it more concrete. If you have removed a method from an interface then you need to find all implementers and users of this method in classes which uses the interface method or any class that does implement this method.
ApiChange can search for implementers and users of specific methods on the command line with the commands -whoimplementsinterface and -whousesmethod. It is not automated at the command line but you can directly use the ApiChange.Api.dll to automate this queries.
Edit1:
I just forgot: The ApiChange tool has actually the functionality you are interested in already. It is the option
-ShowrebuildTargets -new -old [-old2 ] -searchin
We did use it in our department with good results. The only gotcha are the XML Intellisense files. If another target does not use the removed method but references it inside the XmlDoc the compiler will write a warning that a non existing method was referenced. This is quite hard to catch and would involve to parse the intellisense docu files as well. But this is quite an edge case.
I've spent the day looking around for an answer to this. It seems like the tools referenced on the related (unhelpfully closed) questions are now dead or as good as. But I've just taken a look at Telerik's assembly diff tool JustAssembly and this looks much better than rolling your own, which, if you look at their library seems to be a whole heap of work and likely to go wrong.
They have a UI which isn't of that much help from the point of view of integrating into your CI build, it is pretty basic, but you can build the library from source, which I've just done and the library looks like it has everything you need to get yourself up and running pretty quickly.
I would like to implement a Plug-In framework for a C# application; such that the application doesn’t need to know of all of the available .DLL’s at time of compilation but can then be dynamically linked at run time. I expect that I will need to setup some expected parameters to pass information in and out of Plug-In’s but I’m not really sure of what else is needed or how to go about this in C#. Could you point me to a pattern for this implementation or a framework that I can implement to achieve this (if API’s - Open Source license required)?
The Managed Extensibility Framework (MEF) is definitely something you want to take a look at. It's developed by Microsoft, and the stable release version is included in .NET 4.0 and later.
You should have a look at Mono.Addins library. It's open source, easy to use, and really powerful (I think it's even used by MonoDevelop itself).
There are instructions here to create a C# assembly using the SimMetrics library. The link they provided to this library is at SourceForge. It looks like the most recent version of the SimMetrics library was created in Java. Is it possibly to compile java code and then reference it in C# to be used as an assembly in SQL Server 2008?
The best you can do is
compile the java as J# (now obsolete and largely unsupported) with minimal code changes.
this is very dependent on how much of the libraries are used.
convert the code to c# (idiomatic or otherwise)
this can sometimes be fairly easy on highly mathematical code. As an advantage the java code likely assumes 16 bit unicode as well.
use something like IKVM to host the java byte code within the CLR
this may be outright impossible with the sql server hosted runtime, certainly I would think the performance would be poor (since you would have to 'thunk' across the hosting barrier on each call.
The SF page strongly implies that there is both a java and a .net release.
Here's the latest .net release and documentation
However based on the read me file in that
This is an updated version of the original .NET implementation and not a conversion of the newest Java Code.
The .Net implementation is largely c# so you could diff the recent changes in the java implementation then attempt to recreate them in the .Net code. Since the conversion to c# seems to be largely a direct copy with only basic consideration given to idiomatic c# (camel casing, properties and parameter names) you stand a good chance of being able to do this.
If you do consider submitting the changes as a patch, this would give you a chance of getting someone else to validate your changes and may jump start the .Net side of the project to be kept more closely in sync in future.