Open worldspawn opened 9 years ago
This is of course works when installed via the VS package manager. I suspect this is some epic fail on the part of the nuget dev team.
XUnit 2.0 RC3 package suffers from a nearly identical problem
I think that nuget doesn't like our Razor dependency mess...
.NETFramework 4.0
Microsoft.AspNet.Razor (= 2.0.30506.0)
.NETFramework 4.5
Microsoft.AspNet.Razor (≥ 3.0.0)
This has historical reasons and can not easily be fixed in the 3.x release (at least I don't know how, without releasing a bunch of new major versions for the sake of it; we want to align our major number with the Razor package, but failed to do that in the past).
If you need to install the package from command line you can only use a packages.config
file:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="RazorEngine" version="3.6.1" targetFramework="net45" />
<package id="Microsoft.AspNet.Razor" version="3.2.3" targetFramework="net45" />
</packages
or
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="RazorEngine" version="3.6.1" targetFramework="net40" />
<package id="Microsoft.AspNet.Razor" version="2.0.30506.0" targetFramework="net40" />
</packages
When adding the package from within Visual Studio the correct dependencies are selected depending on your projects target framework (so I would urge you to use that instead).
is it possible to add net451 as a dependency ???
@mickdelaney What exactly do you mean, ie what is not working? I just installed RazorEngine on a project targeting net451 and it seemed to work fine.
I was installing webapicontrib.razor with 'update all' in vs. kept complaining about razor v2. Edge case I guess ?
On 11 Apr 2015, at 19:56, matthid notifications@github.com wrote:
@mickdelaney What exactly do you mean, ie what is not working? I just installed RazorEngine on a project targeting net451 and it seemed to work fine.
— Reply to this email directly or view it on GitHub.
I cannot reproduce this, maybe reinstalling all packages from scratch helps.
it was happening on a bunch of projects. its not an issue now as i'm not using webapicontrib so you can probably just ignore me. ;-) i'd kind of assumed that the solution was the sdk redirect (451) etc because it was asking for the 40 version even though i was on 451 but it might well have been some other part of the dependency chain. anyways thanks for your time, its very appreciated.
On 11 April 2015 at 21:50, matthid notifications@github.com wrote:
I cannot reproduce this, maybe reinstalling all packages from scratch helps.
— Reply to this email directly or view it on GitHub https://github.com/Antaris/RazorEngine/issues/243#issuecomment-91924089.
Ok good, thanks for reporting it anyway. If anyone stumbles across this: Either stay on an older RazorEngine version or tell https://github.com/WebApiContrib/WebApiContrib.Formatting.Razor to update (or send a pull request to update) to the latest RazorEngine version.
I do not use NuGet in Visual Studio. Don't care to get into the reasons right now. The proposed packages.config change had no effect when I tried it.
The only way I was able to get these files downloaded so I could use them was to figure out the NuGet gallery's storage conventions and manually get them. For those in the same situation, here's the way to do it: https://www.nuget.org/api/v2/package/{packageID}/{packageVersion} For example, packageID = RazorEngine, packageVersion = 3.6.1 would be https://www.nuget.org/api/v2/package/RazorEngine/3.6.1
The problem exists on the latest RazorEngine version available in NuGet (3.7.0), not just 3.6.1. I got the same error with a simple "nuget install RazorEngine"
There are several projects that rely on RazorEngine as a dependency -- their installations are most likely all broken in the same way if their versions are 3.6.1 or higher.
I still don't know a good way how to fix this, any idea is appreciated. The problem is with all the different builds, combined with all the different Razor versions. And considering the current situation (we need to find a not so painful way out)
Personally, I blame NuGet for allowing the ambiguity and preventing the specificity. As I alluded in my prior post, I don't use NuGet in VS directly, and it's nonsense like this that led me to that decision. Let's just say I'm not surprised to find they didn't fully think this through.
For now, I can pull down what I need with the URL hack that I described. It's definitely better than having to pull down the source for everything.
On a side note: I am very grateful for the work that was put into RazorEngine. It has served us very well.
On Thu, Jul 9, 2015 at 12:47 PM, Matthias Dittrich <notifications@github.com
wrote:
I still don't know a good way how to fix this, any idea is appreciated. The problem is with all the different builds, combined with all the different Razor versions. And considering the current situation (we need to find a not so painful way out)
— Reply to this email directly or view it on GitHub https://github.com/Antaris/RazorEngine/issues/243#issuecomment-120065779 .
Hello,
The following command:
fails with:
using latest nuget 2.8.50926.602