On several different packages like SquishIt and DotNetOpenAuth i get an error saying:
Failed to generate binding redirects for 'MyProject'. Object reference not set to an instance of an object.
I've seen a lot of post about other people having problems with "binding redirects" but not found a single reference to this problem combined with "Object reference not set to an instance of an object.".
What exactly is NuGet trying to do at this stage? Does it try to update the binding redirects in Web.Config? Could i have some issue with my Web.Config? How can i go about debugging this?
I shall say that this does not happen in a "clean" project.
I had the same issue mucking around with MVC versions in one project. I think it could happen for any NuGet package that tries to add Binding Redirects to your config file.
I ended up renaming "Web.config" to "Web.Temp.Config", then installing the package.
I then I manually merged the changes that the package put into my config file into the temp one, then deleted it and renamed my original back to web.config.
This resolved the issue for me - hopefully it helps you.
In my case, update NuGet Package Manager solves the problem.
Related
Cloning a project and it looks like it comes down fine, until I look in the references and they all have the yellow warning triangle. Then my Error List shows all the references as Warnings. My application is on Visual Studio 2017 and it is MVC with C# coding using .NET Framework 4.7.2. In my normal application, original, the references are perfectly fine and no errors and it works great. Builds and works fine. Once I bring down the clone is then the references are lost. I've done a build on the cloned version and it shows all the references as warnings.
I've double clicked a reference and received an error popup box of "This project cannot be viewed in the object browser because it is unavailable or not yet built. Please ensure that the project is available and built". It feels like Azuredev-ops is just missing my references and their location. I am the only one working on this, so there should be no conflicts. I've posted and cloned right after posting, with same result. My code and Web configs look just fine. I have cloned on other people's system too, and same problem with this application. FYI, many of my other applications are working fine using the clone. Just 1 application is having issues. My references are separated in that some are Copy Local True while others are False. I've also removed a reference and added it back, and it comes back with a warning as if it were never added.
Warning message for individual reference:
The referenced component 'EntityFramework' could not be found.
I am also seeing errors for NuGet packages not being there, but when I look I see the package folder with all it's components in it.
It says that for all my windows core references. And just warning symbols in my reference folder for other references.
I am expecting no errors when I bring down the clone. I've upload using my machine and cloning should be able to use the same reference locations. It just feels like AzureDev-Ops is stripping my reference links out, and then going I can't find them.
Azure-DevOps clone shows references as warnings
To resolve this issue, you should make sure of the following:
Make sure you have checked those two options Allow NuGet to download missing packages and Automatically check for missing packages during build in Visual Studio:
Make sure you do not check the \packages folder to the source control.
When you clone the project from Azure-DevOps server and get missing reference error, you should use the NuGet command line Update-Package -reinstall in the Package Manager Console to force reinstall the package references into project. Check this thread for some more info.
Note: Especially need to pay attention to the third point.
Update:
Error:Mircrosoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0
According to the error message, it seems you are not add your packages to your packages source in Visual Studio.
You should publish your custom packages to the nuget feed or you can create you local nuget feed, then add the nuget feed path or local feed path to the package source:
Check this document for some more details.
Hope this helps.
I figured it out. I went to my original and did the Update-Package -reinstall. It came back with the Microsoft.CodeDom.Providers.DotNetCompiler.Platform.2.0.0 not there, but it added one, just not 2.0.0. Then I ran an uninstall of the Microsoft.CodeDom.Providers.DotNetCompiler removing it from my system. Then I posted my original up to AzureDev-ops. My clone came down, not all the references were messed up, some were still, but I did a rebuild and that cleared it up. Thank you to the responses, it pointed me in the right direction.
We use VS 2017 and consume NuGet packages the old way. We do not use PackageReference as of yet.
When a NuGet package reference is updated through the NuGet Manager in VS, the respective assembly binding redirect is not updated automatically - we have to do it manually.
So, I suppose it is up to the package to take care of it through the tools\install.ps1 script. Now, I think I know how to implement it, but I do not want to invent the wheel. Surely the code already exists somewhere, but where?
Clarification
Our application is strongly signed and it targets .NET 4.5.2 currently (soon to be upgraded to 4.7.2). We use packages.config.
I need to explain what is going on. There are three players on the field:
A tool - DbUpgrade
The tool plugin Api - DbUpgradeApi
An implementation of the plugin Api - LogDbUpgradeProgress
Let us inspect the DbUpgradeApi package. 3 versions of it are relevant to us:
The version against which LogDbUpgradeProgress is compiled - A
The version against which DbUpgrade is compiled - B
The latest version of DbUpgradeApi - C
The DbUpgrade tool loads the plugin LogDbUpgradeProgress at runtime. The binding redirects are needed, because A is not the same as B (and because the code is signed, nothing to do here currently)
If C is higher than B, then we should update the reference to DbUpgradeApi in DbUpgrade. But doing so must be accompanied with updating the binding redirect. And this is the essence of this question.
Ok, so I just spent the last hour testing, and I didn't need to do anything that I consider special for binding redirects to work.
But first, are you sure you need binding redirects? .NET Core doesn't need it. If you're using .NET Framework, but with a project using PackageReference, then it's resolved at build time, your app.config doesn't need the binding redirect in the version that's checked in with your code, but when you build and check the [your exe name].config file it does have the binding redirects. Also, binding redirects only matter when your assembly has strong naming. If you didn't sign your assembly, then binding redirect isn't needed.
Here are the steps that I took to create a reproduction of getting binding redirects in a console app using packages.config.
Create an empty folder to start with. I used dotnet new sln, dotnet net nugetconfig to generate a new sln and nuget.config file. I edited the nuget.config file to add the folder localFeed as a source, and set the globalPackagesFolder to gpf so I didn't pollute my real global packages folder with test packages. Also created a strong name key with sn -k snk.snk.
Create first test classlib. dotnet new classlib -n someLib. I edited Class1.cs to change the class name to SomeClass and added a property that retusns the value "Version 1". Used Visual Studio to set snk.snk as the signing key. dotnet pack to generate V1 of the package. I then edited SomeClass to change the message to "Version 2" and then ran dotnet pack /p:version=2.0.0. Finally, used nuget.exe add -source localFeed someLib\bin\Debug\someLib.1.0.0.nupkg and again for v2 of the nupkg.
Create the second test classlib, dotnet new classlib -n anotherLib and set the signing key to snk.snk. Changed Class1.cs to AnotherClass and added a property public string Message => new someLib.SomeClass().Message;. Added a reference to someLib version 1 in the csproj, then built, packed and used nuget.exe to add the nupkg to localFeed.
Opened Visual Studio and created a .NET Framework console app. Added a reference to anotherLib, which automatically brought in v1 of someLib. Upgraded the reference of someLib to v2, and confirmed that packages.config now has a binding redirect for someLib.
Created another .NET Framework console app and did the same as step 3, but this time using PackageReference instead of packages.config. The project app.config doesn't have binding redirects, but the .config file in the bin folder after build does.
edit: perhaps an important part to understanding NuGet/MSBuild binding redirect behaviour is the following: In both steps 3 and 4, if I add a reference only to anotherLib, then no binding redirect is created because all assembles that reference someLib reference the same version. Only by making my console app reference a different version of someLib than anotherLib uses, then the binding redirect is created.
In an app with plugins, the building the app assembly won't have a binding redirect, because it's the only assembly in the compile command line that uses the plugin contract dll, so no conflict to need a binding redirect. When the plugin assembly is built, only the plugin depends on the plugin contract dll, so again no conflict so no binding redirect. If you copy all the dlls into a single folder, then there can be a conflict in the required version, but this is a deployment time issue, not a build/compile time issue, so build tools may not help. One way to resolve this would be to add a reference to the plugin project from the app assembly. This way at compile time the build tools can see that two different versions of the plugin contract dll is used, so a binding redirect can be created. This only works if you build the app assembly. If the app is just a binary that you're given, then changing the binding redirects becomes a deployment time responsibility, so development/build tools may not help.
I downloaded the TFSBranchTool VS Extension Project.
Rebuilt and Installed, but when I try to apply Initial Structure I get the following Error:
Exection Error:
Exection of Action 'ConnectSourceControl' Failed. Details: Could not load file or assembly Microsoft.AlLMRangers.BranchTool.SourceControlWrapper......
Any idea what might be causing the problem ? I tried on 2 different Servers! , I got the latest Update of VS2012.
I got VS2012 SDK installed and Vs2012 ObjectModel too, not sure what I'm missing!
We have posted an update to the sample code on http://vsarguidance.codeplex.com/releases/view/96222, which addresses this bug.
The issue was that Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll was missed in VSIX package. As action execution engine using MEF to load actions, it has no direct references to actions implementation assembly.
Vladimir from the team fixed the issue by specifying assembly as the MEF asset in the VS extension’s manifest file. Now it’s redistributed inside the extension package.
Can you verify that you have the file Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll
in the following folder:
%LOCALAPPDATA%\Microsoft\VisualStudio\11.0\Extensions\Microsoft. ALM Rangers\TfsBranchToolVSExtension\1.0
If its not there - try deleting the TfsBranchToolVSExtension and re-install the VSIX.
I am evaluating PostSharp for a new project but cannot seem to get past the following error when I first build the project after changes:
Cannot copy file "C:\SourcePath\Output\Debug\MyApp.vshost.exe to
obj\Debug\Before-PostSharp\MyApp.vshost.exe: the file is locked by
process(es):MYAPP.VSHOST (8064)
The error only occurs in the first build attempt. If I immediately re-build, the error does not occur. I can only guess this is because the project isn't actually being rebuilt the second time.
I've read a few posts in the SharpCrafters forum that indicate this problem existed prior to v2.1 but was reportedly fixed. I am using v2.1.6.14 from NuGet (in VS 2010) and getting this error for every project I reference PostSharp. It is certainly not reasonable to require 2 builds every time, so I'm looking for a possible solution. I'm really pleased with what I've seen thus far but will have to go another direction if that can't be resolved.
UPDATE
Per Gael's request, I generated the diagnostic build log and sent it to him and it looks like he was able to resolve the problem in the latest release (2.1.6.14).
I believe part (or all) of the issue may be due to the fact that the build output for all of my projects is set to a common location (i.e. not the /bin/debug folder under each project). This is because we are using a MEF DirectoryCatalog which will discover Imports and Exports contained in the assemblies located in the output path. The PostSharp.targets file has the vshost.exe file excluded from the copy operation but only when it shares the name of the output assembly. In my case, the vshost.exe file has a different name and was, therefore, not being excluded.
The issue has been re-fixed in PostSharp 2.1.6.15.
I have an ASP.NET MVC 2 application.
Web project contains a reference to SomeProject
SomeProject contains references to ExternalAssembly1 and ExternalAssembly2.
SomeProject explicitly calls into ExternalAssembly1, but NOT ExternalAssembly2.
ExternalAssembly1 calls into ExternalAssembly2
When I perform a local build everything is cool. All DLLs are included in the bin\debug folder. The problem is that when I use the Publish Web command in Visual Studio 2010, it deploys everything except ExternalAssembly2.
It appears to ignore assemblies that aren't directly used (remember, ExternalAssembly2 is only used by ExternalAssembly1).
Is there any way I can tell Visual Studio 2010 to include ExternalAssembly2?
I can write a dummy method that calls into ExternalAssembly2. This does work, but I really don't want to have dummy code for the sole purpose of causing VS2010 to publish the DLL.
None of these answers are sufficient in my mind. This does seem to be a genuine bug. I will update this response if I ever find a non-hack solution, or Microsoft fixes the bug.
Update:
Doesn't seem promising.
https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I am having this same problem (different assemblies though). If I reference the assemblies in my web project, then they will get included in the publish output, but they should be included anyway because they are indirect dependencies:
Web Project ---> Assembly A ---> Assembly B
On build, assemblies A and B are outputed to the \bin folder. On publish, only assembly A is outputed to the publish folder.
I have tried changing the publish settings to include all files in the web project, but then I have files in my publish output that shouldn't be deployed.
This seems like a bug to me.
I had the same problem with VS2010 and a WCF Service Application.
It turns out that if your (directly or indirectly) referenced DLL's are deployed to GAC, the VS publishing feature excludes them. Once I removed the assemblies from GAC, publishing feature started working as expected.
I guess VS is assuming that if your assemblies can be located in GAC on the machine you build, they will be located in GAC on the target machine as well. At least in my case this assumption is false.
My tests show that the external assemblies get published when I have a reference on them in the web project. I do not have to write any dummy code to make it work. This seems acceptable to me.
I agree with Nicholas that this seems to be a bug in visual studio. At least it escapes me what the reason for the behavior could be.
I have created this issue as a bug on Microsoft Connect. If anyone experiencing it could vote it up https://connect.microsoft.com/VisualStudio/feedback/details/637071/publish-web-feature-not-including-all-dlls then hopefully we'll get something done about it.
If you go into the ExternalAssembly2 reference property list and change the "Copy Local" to "True" i think that might solve your issue.
I don't know if you are watching this still but I found the solution (I had the exact same issue) via this MSDN article. Under "build action" for the file choose "Content" that should include it in the list of files publish brings over.
I have created a new Connect bug here https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I've also attached a solution and detailed steps to reproduce this issue. Lets hope this time they won't close it as Can't Reproduce.
Vote for this connect issue if you experience the missing dll problem.
Copy local did the trick. I had an issue that the Newtonsoft.Json assembly get included in the deploymeny package. Copy local was set to false.
I am experiencing the same type of issue with a web project. I have a web project that references assembly A which references assembly B. It worked fine for some time but today it was broken. I did a rebuild of the solution and this time it deployed everything correctly.
I had this same problem today. I published my web project and realized that not all of the reference DLL's were there. In particular, the indirect DLL references.
It turns out that the directory in which I was publishing to was out of disk space (network share). I had just enough space to publish all the files except for few indirect reference DLL's. The sad part is that VS08 didn't throw any errors. It just published the files are usual. I cleared out some HDD space and everything worked fine.
I didn't find the HDD space issue until I tried to manually move the DLL's over.
in my case it is quite tricky.
Reference to ExternalAssembly2 is not required to Build the project but vital for run-time since we use reflection to configure Unity container.
So, I delete the reference - build the project successfully, but get run-time error.
If I preserve the reference I can Build and Run the application but I cannot Publish it with ExternalAssembly2 - get run-time exception as well.
This is happen because of internal VS2010 assemblies optimization.
So, what we can do here?
1. Put some unrequired peice of code to use any ExternalAssembly2's class.
2. escape from reflection and use static assemblies linking.
Hope this helps to smbd.
I got the same problem and this is a VS2010 bug if there's a reference link like:
Web Project --> custom project --> assembly1 -->(indirectly) assembly2.
For now I find if I reference the Assembly1 in the web project, then assembly2 is included in the bin folder.
So I had to add an additional reference link like:
Web project --> assembly1 -->(indirectly) assembly2.
Then VS can recognize assembly2 and include its dll file in publish action.