I upgraded my MVC 4 app to MVC 5 a couple of days ago following these instructions and now I'm getting the following error. I updated DotNetOpenAuth to the latest bits using Nuget (v4.3.3.13295) but it still throws this error.
How do I fix this?
Inheritance security rules violated by type:
'DotNetOpenAuth.Messaging.OutgoingWebResponseActionResult'. Derived
types must either match the security accessibility of the base type or
be less accessible.
Solved this finally. Turned out that I needed to make some changes to the source code of DotNetOpenAuth and re-compile it. This wasn’t easy at all since the source code won’t compile after downloading from github. I had to spend ~3 days trying various things and learning the build system meshed into DotNetOpenAuth’s project files until I finally got it to compile. Seems the author of this project has abandoned it. See more about this issue here.
Download the 4.3 code base using this command line: git clone -b v4.3 https://github.com/DotNetOpenAuth/DotNetOpenAuth.git
Edit the /src/version.txt and change it to 4.4.0. This makes this version higher than the official Nuget release so that installing Nuget packages don’t attempt to install old versions of DotNetOpenAuth assemblies from its repository.
Remove all instances of the following string from all AssemblyInfo.cs files under the /src/ directory.
[assembly: AllowPartiallyTrustedCallers]
I had to mess around with the Microsoft.Contracts reference in two projects and point it to /tools/Contracts/PublicAssemblies/v3.5/Microsoft.Contracts.dll and then use a using alias to get classes from this assembly to resolve properly. A few Requires.NotNull() lines refused to compile so I just commented them out… c'est la vie..
Run the following command to skip verification of these assemblies: sn.exe -Vr *,2780ccd10d57b246
Once the assemblies were built I referenced those, re-added Microsoft.AspNet.WebPages.OAuth 3.0 from Nuget, rebuilt my solution, and finally my app is up and running on MVC 5.
Related
What I've been strugling with for some time:
I have a "traditional" (i.e. non-SDK) csproj file. I want to create a nuget package. That's easy but devil hides in the details and I end up in the following catch-22
I can manually call nuget pack .\Foo.csproj, with or without a nuspec file, but then I get the dreaded NU5128 error. The chosen answer suggests to simply ignore the error. I would happily do that, but after publishing the package locally, I noticed that the dependencies are not included. Though there is one dependency to JSON.net that I added for the sake of testing. The same error appears in AppVeyor if I configure my yml to create the package.
I can specify all the packaging related properties in the .csproj file by setting GeneratePackageOnBuild to true. It works and takes the dependencies right but then I can't patch the version like I could do with the replacement tokens of nuspec. The version defaults to 1.0.0.0 even if I change it in the AssemblyInfo.cs to 1.2.3.4.
Notes
This answer suggests that nuspec and csproj configuration can coexist and they are merged. The question is from 2013 so I guess it's not referring to SDK projects. Unfortunately that's not the case for me.
I tried adding a <NuspecFile> in the csproj but then it seems that replacement tokens don't work and I get the error described here. Probably because this instructed nuget to run pack on the nuspec instead of running it on csproj and merge the nuspec. I can't know for sure though as setting the build verbosity to Detailed didn't help to understand what nuget pack tried to do.
Getting the AssemblyInformationalVersion in msbuild and use it straight to the <Version> property isn't as straightforward as one might think and it also defeats the purpose as $version$ is doing exactly that according to the documentation:
AssemblyInformationalVersion if present, otherwise AssemblyVersion
Is there a way to really "merge" .csproj and .nuspec with $version$ patching and get the dependencies in the nuspec right?
So far the best course of action was to convert the project to SDK format. It has several advantages. Less configuration, no need for .nuspec file, no need for AssemblyInfo.cs or VersionInfo.cs files, .nupkg dependencies are correct and AppVeyor can patch directly the .csproj file if it's an SDK project file.
Not a solution per se if one wants to keep the legacy format, but it gets you going with the CI/CD instead of having you fighting with tools.
This use case might be a bit off-label, but I'm hoping someone can help me...
For a number of years I've maintained a "library" of MSBuild commands -- in a file we'll call CommonTasks.targets, distributed through our internal NuGet server -- that handles various tasks needed by my company's projects. For the last few years I've utilized GitVersion v3 with it, both for generating the library's own NuGet package version numbers as well as utilizing GitVersion's GetVersion MSBuild target directly (e.g., when generating a corresponding git tag), to avoid needing to extract the GitVersion-generated version from the dependent project's assembly, post-build.
Previously (with GitVersion v3), all that was required was for my CommonTasks.targets file to import the GitVersionTask.targets file located in GitVersion's NuGet package at \build\dotnet\GitVersionTasks.targets. This targets file in turn executed the necessary UsingTask commands (particularly GitVersionTask.GetVersion) which then let me call <GetVersion ...> in my own .targets file after the import.
With v4, GitVersionTask has introduced a dependency on UtilPack.NuGet.MSBuild (which I gather helps with various NuGet commands). To start with, that meant that I needed to import its UtilPack.NuGet.MSBuild.props file, or GitVersionTask wouldn't load at all. However, having done that, I now get unexpected errors attempting to call GetVersion from within an MSBuild file. Seemingly, the GetVersion target now attempts to query all my defined NuGet repositories (nuget.org, local caches, our company server, etc.) for the packaged version of my library, and at the end I'm greeted with this error:
MSBUILD : NuGetTaskRunnerFactory error NR0001: [NuGet Error]: Unable to find package CommonTasks with version
(>= 1.37.0-gitversiontask4-0001) [C:\redacted\CommonTasks\Build.proj]
MSBUILD : NuGetTaskRunnerFactory error NR0001: - Found 108 version(s) in Source1 [ Nearest version: 1.36.3 ] [C:\redacted\CommonTasks\Build.proj]
MSBUILD : NuGetTaskRunnerFactory error NR0001: - Found 42 version(s) in Source2 [ Nearest version: 1.36.3 ] [C:\redacted\CommonTasks\Build.proj]
MSBUILD : NuGetTaskRunnerFactory error NR0001: - Found 0 version(s) in Microsoft Visual Studio Offline Packages [C:\redacted\CommonTasks\Build.proj]
MSBUILD : NuGetTaskRunnerFactory error NR0001: - Found 0 version(s) in nuget.org [C:\redacted\CommonTasks\Build.proj]
MSBUILD : Task factory error NMSBT003: Failed to find main package CommonTasks#. [C:\redacted\CommonTasks\Build.proj(47,9): error MSB4175: The task factory "Ut
ilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\redacted\CommonTasks\packages\UtilPack.NuGet.MSBuild.2.7.0\build\\net46\UtilPack.NuGet.MSBuild.dll". Object ref
erence not set to an instance of an object.
What I don't get is why it's attempting NuGet retrievals at all, and, even if that's the new default behavior, I don't know a way to disable that, or barring that, I don't know why it's not working. I assume the error must have something to do with this not being a normal .NET project (i.e., with no source code aside from a .targets file, no .csproj file, etc.). But my library is used by many normal .NET projects, which themselves use GitVersionTask to auto-version their assemblies.
For now I've pinned my library to GitVersionTask v3, but would very much like to figure out how to allow it to use v4 as I'd been using v3 previously. I could likely switch to using the GitVersion.CommandLine package instead, and parsing its output, but I ultimately do need these GitVersion-generated versions as MSBuild properties in order to use them as intended. And with dependent projects also using GitVersionTask (not the CLI), it's convenient to be able to use a single package for both.
Is there a way to fix what I'm doing with GitVersionTask v4, or some completely different (perhaps more elegant) way to achieve what I'm trying to do?
OK - here we go again. I posted an almost identical question here, but this one is a little different. I just generated a new version of a NuGet package and updated all of our csproj and config files to point to it and it builds locally fine, but when I kick off a TFS build it fails with the message:
##[error]ASPNETCOMPILER(0,0): Error ASPCONFIG: Could not load file or assembly 'PacsgearLib, Version=2.5.4.0, Culture=neutral,
PublicKeyToken=05b30ac9ab9dbb8e' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
Pacsgearlib 2.5.4 is the NuGet package I just generated, but all of our other projects build fine (and they share a lot of the same code). The main difference is that this project has a website in it. MSBuild is version 15.5.180.51428.
Here's a picture of the actual error:
Any ideas here? I've tried NuGet package manager to uninstall the package and reinstall it for the website and that hasn't helped.
I've been at this for a few hours so I thought maybe someone else (or a second set of eyes) might help.
I also just saw this and will check it out first thing Monday morning.
I finally got this to work by taking out the assemblybinding section of the web.config (someone else suggested that in another related post) and I also found a few .csproj files that had not been properly updated and were still pointing at 2.5.3.
If the local builds fine, and the error exist with TFS build. Besides, all of our other projects build fine (and they share a lot of the same code).
Combine with both, the issue may related to the specific package PacsgearLib, Version=2.5.4.0 on build agent. You could try to delete the packages and clean build agent, then try again.
Another way is update your package version number(do not update the package content), use TFS trigger the build again. Check if TFS build server will pick up the latest version of package.
Also set system.debug=true to Enable Verbose Debug Mode with more detail log info for troubleshooting
I have a solution which contains an asp.net 5 app, a code library, and a test library. The libraries are also the new project.json style. I am not really sure how to refer to these libraries to distinguish them from the existing library project structure.
Anyway, all three projects were targeting dnx451/net451. I decided to try targeting dnx46/net46. The libraries build, but the asp.net dnx app fails. The error is:
The design time host build failed with the following error: Object reference not set to an instance of an object.
It is referencing the file Microsoft.DNX.targets at line 166.
There is another error that just says, "Object reference not set to an instance of the object." It says line 1, but doesn't reference a file.
To test I created a new solution with and empty asp.net 5 project and 2 class libraries. I changed dnx451 to dnx46, and net451 to net46, and it compiles fine. I am not sure what in my existing project is causing this error, or where to start looking.
By the way, dnx46/net46 are the only frameworks targeted. I have removed the core frameworks.
What a load of trial and error. Turns out the issue was the razor precompilation module as described here, http://davidzych.com/view-compilation-in-aspnet-5-with-the-razorprecompilemodule/.
You can read the github issue here, https://github.com/aspnet/dnx/issues/3003.
I first tried to comment out the precompilation class. However just that fact that the file was there, made dnx throw the error. I removed the precomilation file and now it compiles fine.
EDIT:
Alternatively you can add dnx451 back into your project, along with dnx46 and then the precomilation module will work fine.
I have tried to get NuGet running on Mono 2.10.9 (Mac), but with no luck.
I want to install Nancy from the NuGet repository:
mono --runtime=v4.0 /usr/local/bin/NuGet.exe install Nancy -Version 0.11.0
But, end up with this error message:
Missing method System.Security.Cryptography.CryptoConfig::get_AllowOnlyFipsAlgorithms() in assembly /Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/4.0/mscorlib.dll, referenced in assembly /usr/local/bin/NuGet.exe
Method not found: 'System.Security.Cryptography.CryptoConfig.get_AllowOnlyFipsAlgorithms'.
I can list the repositories without problems.
mono --runtime=v4.0 /usr/local/bin/NuGet.exe list Nancy
I have tried to add Microsoft.Build.dll to the same path as NuGet.exe (a tip from a site. I can't remember where).
I end up with this error:
Invalid type Microsoft.Build.Evaluation.Project for instance field NuGet.Common.MSBuildProjectSystem:<Project>k__BackingField
Could not load type 'NuGet.Common.MSBuildProjectSystem' from assembly 'NuGet, Version=2.0.30619.9000, Culture=neutral, PublicKeyToken=null'.
Any suggestions on how I can get NuGet.exe running on Mono (Mac)?
I'm afraid you can't do that with the version of Mono you have installed.
That particular release (2.10.9) did not include the static property:
System.Security.Cryptography.CryptoConfig.AllowOnlyFipsAlgorithms
which seems to be required by NuGet.exe "install" feature.
The "list" command probably works because it doesn't make use of the cryptography assemblies (in .NET assemblies are lazily loaded, only when executing code requires them).
On a positive note, it seems like in the github version of Mono the CryptoConfig class was updated with this property, as you can see here:
Current mono CryptoConfig.cs source, on master branch
This shows the change should have been included in the 2.10.9 release:
History of changes on mono's CryptoConfig.cs
The AllowOnlyFipsAlgorithms property was added on May 2nd 2011, a full year ago, and yet it's not in the current stable release!!!
Which is weird...
You could try downloading the alpha release (Mono 2.11.2) and see what that does for you.
P.S.
I've looked at the sources for the 2.11.2 alpha version and it looks like this property is included in this build, so give it a try.
Hope this helps.
There are several steps you need,
Install all mono assemblies (so as to get WindowsBase).
Import certificates.
Get Microsoft.Build.dll.
Then you should be able to run NuGet. I documented more details here,
http://www.lextm.com/2013/01/how-to-use-nuget-on-mono-part-i.html