LinqBridge Breaks Razor Views: .NET Version-Based File Output Restriction

Question

Our project uses several NuGet packages, a few of which reference LinqBridge, a library that re-implements LINQ to Objects for C# 2.0. The LinqBridge.dll file lives under /packages/PackageName/lib/20/LinqBridge.dll, so it clearly is supposed to only apply to .NET 2.0.

The problem is that, even though every project in the solution is configured to build to .NET 4.0, the LinqBridge.dll binary gets copied over to the final /bin directory and wreaks havoc in Razor views. If I perform .Select() on an IEnumerable, there is an ambiguous call between the built-in LINQ call and the re-implemented one that LinqBridge provides.

I clearly do not need the re-implemented version; if I simply delete LinqBridge.dll from the output /bin directory, everything works just fine. However, that is not an acceptable permanent solution.

Is there any way I can configure something to quit copying that file, which is for an old .NET version, into the /bin output?

Edit: I duct-taped together a solution by adding this to the "Post-build event command line:" commands under "Build Events" in my solution properties:

del $(SolutionDir)\bin\LinqBridge.dll

It's still far from ideal, but at least it lets my project run for now.

Answer 1

NuGet has support for different binaries for different .NET versions so I would suggest that the packages you are using are built badly.

I would contact the authors of the packages and see if they can fix them so that only the net11 or net20 versions include LinqBridge.

Supporting Multiple .NET Framework Versions and Profiles

Many libraries target a specific version of the .NET Framework. For example, you might have one version of your library that's specific to Silverlight, and another version of the same library that takes advantage of .NET Framework 4 features. You do not need to create separate packages for each of these versions. NuGet supports putting multiple versions of the same library in a single package keeping them in separate folders within the package. (more...)

Answer 2

A useful approach we found was using the LinqBridge.Embedded Nuget package instead of the standard LinqBridge package. This embeds Linqbridge as a C# file within your project, and hence does not get copied over to the bin folder and loaded into the context of the Razor view.

This was useful to us because an assembly we reference still needs to be built in .Net 2.0, as it is also referenced by a 2.0 application. Hence that assembly uses LinqBridge.Embedded, and the LinqBridge assembly does not end up in our 4.0 servers' bin folders.