Related
I have a VSIX extension which I have migrated to a new solution (basically to remove older projects targeting older VS versions no longer supported by my company) and to simplify the codebase for ease of maintenance.
Within the IDE, it does not matter if I set the active configuration to Debug|x86 or Release|x86, it will build a VSIX artifact OK. All good so far.
If I use
MSBuuild /t:Build /p:Configuration=Release /p:Platform=x86 -restore -detailedSummary MyExtension.sln
it will build without any errors, but no VSIX is produced.
I have poured over the terminal output and there are no warnings/errors and the DLL output of projects in the solution are produced.
I did read the following:
Project not selected to build for this solution configuration
The option to click deploy from the above link is not available for my VSIX - all the deploy options are disabled.
I have searched S.O. for similar issues regarding a VSIX not being produced, but none seem apt.
How should I debug this? What is different about a command-line MSBuild from the in-IDE build? Hopefully somebody has had a similar experience and can let me know what was causal for them, so that I can give something a try.
Update 1:
It transpired that although I was targeting .NET Framework 4.6, some .csproj references copied over from the migrated project had entries for net472, despite NuGet packages themselves being selected for compatibility with .NET Framework 4.6.
I had to manually edit a few .csproj files. There were some reference issues in associated projects that then needed fixing.
The residual issue now is as follows:
The in-IDE build fails with a single error...
A PackageReference to Microsoft.Build.* without ExcludeAssets="runtime" exists in your project. This will cause MSBuild assemblies to be copied to your output directory, causing your application to load them at runtime. To use the copy of MSBuild registered by MSBuildLocator, set ExcludeAssets="runtime" on the MSBuild PackageReferences. To disable this check, set the property DisableMSBuildAssemblyCopyCheck=true in your project file (not recommended as you must distributed all of MSBuild + associated toolset). Package(s) referenced: Microsoft.Build.Framework
So I grepped my source code folder for <PackageReference Include="Microsoft.Build and only a single project was in the result list. When I checked this project file, the entry in question did have ExcludeAssets="runtime" so I am unsure why the error is reported. I have tried project cleans followed by rebuild, or deleting bin and obj folders before building, to no avail.
I guess my question now is whether <Package Include="Microsoft.Build are relevant, since these are not <ReferencePackage Include elements as mentioned in the error message.
Update 2:
I hang my head in shame. PBKAC regarding Update 1 error. I had sent a copy of the code to a build engineer who committed it to a branch in our VCS. I then cloned this branch to a different location, and copy+pasted my more recent changes over the top. However, the grep tool (AstroGrep) I was using was still pointing at the older location not in the VCS. The older location contained package references with ExcludeAssets="runtime" as required. However, the newer location did not. Once I noticed this, I corrected it by editing the faulty .csproj file and the error from Update 1 went away.
However, I still appear to have the original issue the question is about.
I am awaiting my company's security team to approve the use of MSBuildLog so that I can get more detail and hopefully find the cause.
One other commenter suggest moving to solution PackageReference build rather than using packages.config. There is a question as to why this is needed. I am aware this seems like it could create a significant amount of extra work due to: this for which there are workarounds, but the commenter mentioned a "need" to use NuGet this way, when I think it is optional. I wish to understand more before committing to such a change.
Unfortunately, this is one of those things where it's a case of user beware.
When using NuGet, it is possible for it to appear to have succeeded in updating a NuGet reference, but unless one checks the underlying packages.config meticulously, you may not be getting what you think.
As I am migrating a solution that used packages.config instead of <Project Reference .../> elements in .csproj files, I have been caught out by IDE default behaviour changes.
NuGet seems to update the .csproj using <PacakageReference.../> elements by default. But this does not amend the packages.config entries that may already exist. As such, I ended up with a mish-mash that MSBuild seemed confused about at build time. Rather than throw an error, it just did not build what was expected.
The old packages.config files had entries targeting .NET Framework of net472 in some cases. I was adding NuGet references to earlier versions for net46 since this is what I need to target now, and this resulted in the problem behaviour, since any unchanged net472 entries were no good for producing the build output.
Since the project needs to support VS2015 also, I need to rely on packages.config approach and not <PackageReference.../> approach, which was not updating older references in the expected way.
As such, I had to remove the NuGet <PacakgeReference.../> and re-introduce correct package versions in packages.config. Once these were all correct, the VSIX built OK.
Due to some git project changes, when I try to build, I get an error:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\MSTest.TestAdapter.1.1.11\build\net45\MSTest.TestAdapter.props.
The references to the project contain four missing references, two of which Microsoft.VisualStudio.TestPlatform.TestFramework, and Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions which seem to be related.
The other two, in case it proves to be relevant are System, and System.Core, but they aren't causing any problems... which is weird, cause I'm definately using them.
That missing file, the one from the error message, is absolutely there.
I've tried to uninstall and reinstall both packages, but nothing seems to help.
Open the projects .csproj file with your favourite text editor and delete any references to
MSTest.TestAdapter.props.
Edit: This is safe to do so, all that happened is that you have removed the DLL but for one reason or another your project file still references it as a dependency.
I would modify #JoshuaDuxbury's answer to say: you need to clean out obsolete references to MSTest.TestAdapter.props.
In my case, I had just updated the MSTest.TestAdapter NuGet fronm 1.3.2 to 2.0.0, but apparently when I did that, Visual Studio didn't clean up my .csproj file perfectly.
So, I had to delete the superflous MSTest.TestAdapter.props highlighted in two places:
Near the top of the project file:
...and again at the bottom of the file:
Once I did that, my CI pipeline was able to build everything correctly again.
Some of you with sharp eyes may notice something funny w/the 1.3.2 of MSTest.TestAdapter shown above: it seems the path to the packages folder is off! But that would be a topic for a different thread (or maybe an alternate explanation to why your build pipeline is unhappy.. maybe just fix your path to packages).
My issue didn't occur on my development box but on the Azure Build Pipeline. I removed the offending props files as per the other answers but to no avail. Ultimately I had to add the Nuget restore step to my the Azure build pipeline and move it to the proper slot before the building:
I have no idea how I've done it but I've had the same error and I thought the files were here but they actually weren't... so anyone who has this issue double check the paths.
In my case the Packages folder was at the same level as the project file however it was looking for files in the parent directory. Nuget restore and Update-Package -reinstall
were not fixing anything.
Windows 8.1 Enterprise x64, Visual Studio 2015, MVC 5, EF 6, VS Online using git
I'm a relatively new developer with Visual Studio (about nine months), and ever since I started I've had an incredibly difficult time with references and NuGet packages. All of my references were working correctly on Friday when I shut my computer down for the weekend. I didn't touch the computer at all the entire weekend, now I've booted up today and I have a ton of reference errors:
(There are 6,262 errors total but I obviously can't screenshot the entire thing.)
Like I said, this sort of problem occurs very often, and it's incredibly frustrating. Things I've tried:
Ensure all references throwing the errors actually are referenced
Un/reinstall the packages throwing the errors in NuGet
Completely delete the contents of the packages folder and let NuGet restore them (all reinstalled, views have the same errors as before)
Ensure every single reference is set to Copy Local
Close the solution, delete all bin and obj folders, reboot computer, clean, rebuild
Ensured all necessary references are in the relevant web.config (either inside Views or at the root)
Check for NuGet option to restore missing packages (did not appear, all packages are in my local packages folder)
Other things on SO that I'm sure I've forgotten to list here
I'm at my wits' end with these packages and references. It's a different fix every time, and this time I can't figure it out. Am I missing some obvious fix, something I overlooked? Is there a way to somehow take a backup when this is working and restore it whenever things break? Any ideas whatsoever, whether helping with the current problem or for fixing the underlying problem, would be very much appreciated.
Additional note
The problem is NOT only with views--controllers are also throwing errors. Specifically:
The type or namespace name 'Controller' could not be found (are you missing a using directive or an assembly reference?)
(It literally says Controller, that's not something I changed for privacy or whatnot.)
These are thrown despite the fact that I have using statements for all of the necessary namespaces. The using statements themselves work properly, but the error is thrown in the code. The automatic fix suggested is to manually reference everything: for example, var sb = new StringBuilder(); wants me to change the line to var sb = new System.Text.StringBuilder();. Testing that fix does not correct the problem, the same error is thrown but on System instead of StringBuilder.
Additional requested information
I use git with VS Team Services (but packages are ignored with .gitignore).
I and one other person work on this, but the other person hasn't touched it at all (not even pulling from the remote repo) in several weeks.
References in the .csproj file are in the format ..\..\..\packages\ (correct for the location relative to the .csproj file).
Targeting .NET 4.6 (always have been, that's not new)
All references resolve, no exclamation marks in the references list.
New Projects
There is one single thing you need to do in order for packages to work correctly with git:
When you create a repository, make sure you add a .gitignore tailored for Visual Studio development. You can search google for such a file or take it from here.
This will make sure you don't commit anything that will cause problems later.
This should solve a lot of the problems that usually happen when you check in packages to a code repository. You can add/remove packages and upgrade packages and also be able to clone the repository to a new machine and packages will be restored automatically.
Existing Projects
This is good for new projects. If you already have a project with a great big mess, then it is very hard to fix it since Visual Studio keeps package versions in several places - packages.config and app.config (and web.config where relevant).
Option 1 - Fix the current project
You can remove all packages (remove all the references from all projects and delete the package contents).
Make sure that the packages no longer appear in any file (e.g. packages.config or app.config). Now add the .gitignore and then start adding the packages back.
Option 2 - Create a new project
If it doesn't work, start a new project, add the .gitignore, transfer all the code (only your code) and install the packages.
I'm not quite familiar with how Git works in VS, but I recall one time recently when using TFS that unbinding the solution from source control, fixing all packages, cleaning and re-building before binding it again solved a bunch of issues regarding NuGet references.
I apologize if Git works way different within VS.
I am trying to get the async nuget package for .net 4.0 to work but it doesn't seem to work. Ive uninstalled the package, restarted VS 2013, and reinstalled the package about 10 times now. Ive tried manually copying the file and right clicking add > add existing.
Here is the thing I get the following error each time...
Could not load file or assembly 'Microsoft.Threading.Tasks, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
So for some reason it is looking for version 1.0.12 but i have only ever installed version 1.0.168 (the latest) so I have no idea on earth why it would be looking for version 12 and I cant find where this setting would be. I tried the packages.config file but it lists it correctly at version 1.0.168
what the heck!? how can I tell this to look for version 1.0.168 instead!! Please help me!
Usually this happens when there is an issue with packages.config. It happened to me a couple of times in the past. Just review your packages.config and make sure that its definition matches with the version you need.
If packages.config is not the issue you can try:
Removing the nugget from the solution (right click on the solution and click manage nugget packages for solution) and re-installing it.
Update nugget packages in all your projects to require the same version of the assembly. Maybe another project is dependent on the old version.
If the reference that you have in the project is for the wrong version, then FIRST uninstall the nugget, then remove the reference from the project and then try to either re-install the nugget, or manually reference the correct assembly.
I also forgot to mention that you can also remove the entry in packages.config, but this is not a good solution (unless you are 100% sure you will only use this library from one assembly), as it will cause problems when difference projects in your solution will need to reference that assembly.
I had a similar issue, where VS insisted on using a specific version, which was not available anymore.
Restoring and rebuilding did not seem to help.
Lastly, I went for msbuild dirs.proj and that resolved the issue for me.
I have a solution with 3 projects:
ParsersBase, that defines an interface IParseRule
ParsersLibrary, that has a reference to ParsersBase and defines a class HtmlImageUrlParseRule : IParseRule
ParsersLibraryTest, that has a reference to ParsersBase and ParsersLibrary and defines a test class with some test methods
When I'm trying to build it, I get a warning:
Reference to type 'AVSoft.ParsersBase.IParseRule' claims it is defined in 'c:\Users\Tim\Dropbox\projects\Image Downloader\ParsersLibrary\bin\Debug\ParsersLibrary.dll', but it could not be found
Why is VS trying to find AVSoft.ParsersBase.IParseRule in ParsersLibrary.dll? ParsersLibraryTest has a reference to ParsersBase; it just doesn't make any sense.
Another way this could happen is if you're using several NuGet packages where one, probably central, package has been updated but some additional functionality packages haven't been.
To work through my recent example - the error was "Reference to type 'ConsumerSubscriptionConfigurator<>' claims it is defined in 'MassTransit', but it could not be found". This is because we had updated MassTransit from 2 to 3, but we had not updated some of the other optional packages (MassTransit.log4net and MassTransit.Autofac) to the same version number. It appears as if assembly redirection had kept everything working until we tried to use one more additional feature.
This error seems to cover a variety of scenarios. In my case, closing and re-opening Visual Studio was the trick. After restarting Visual Studio, I was able to build the project as expected.
I had a similar problem. The site was running a cached version of the dll and not the one I had deployed to the bin directory. I cleared the temporary asp.net folder contents and this solved the issue.
It was my fault, I had a ParsersLibrary project at the start and then renamed it to ParsersBase, but I didn't rename an assembly name, then I added a ParsersLibrary project again.
So, two projects had the same assembly name and it's not very good, is it? :) Assemblies overlap each other, so I have this error.
I had the similar problem: Reference to type 'Func<>' claims it is defined in 'mscorlib', but it could not be found. The problem was following: my solution had Target Framework = 3.5 and I added a reference to Microsoft.Practices.Prism v 4.0 which is built against the framework 4.0.
After changing target framework to 4.0 it worked
It looks like things are a bit easier now than they were before.
As other answer(s) have basically already stated, this error can result from an older version of the same NuGet package not having some of the newer types in it. While in production, this is generally managed through proper versioning, in development, you may end up reusing the same version number when making changes. And that's a likely place where this problem can arise.
To fix this, you can often just clear the cache by doing the following:
In Visual Studio, go to Tools > NuGet Package Manager > Package Manager Settings.
In the pop-up menu, navigate to NuGet Package Manager > General.
In the options on the right, click Clear All NuGet Cache(s).
I hit this exception today. The problem in my case was I had some.package v2.1installed in my host and some.package v2.3 installed in other projects. Update-Package on the host project to v2.3 fixed the issue.
I my case, I tried to test a WPF project with a .NET Core (3.1) test project which could not reference the needed WindowsBase.dll.
Updating/consolidating packages didn't help. Even a clean repo and a restart of Visual Studio didn't solve it for for me.
But rebooting did fix the problem!
#binki's comment helped me;
deleting all .vs, bin, and obj folders, and then reopening the project
ParsersLibraryTest needs to reference ParsersBase. The second part of the error should read "You must add a reference to assembly 'ParsersBase..."
I tried all of the above answers but none resolved my issue.
In the end, I checked in my latest code (GIT), then recloned the repository in a different location.
Not ideal, but at least problem solved.
I had the similar problem: Reference to type 'Func<>' claims it is defined in 'mscorlib', but it could not be found. I have a lib of .Net 4 that was referenced by a .Net 3.5 program. After upgrading both to 4.61 it worked.
Seems like Func<T> is missing in .Net 3.5 and just upgrading that sample app would have been enough.
Further exp: Someone had added a signature in the library project (.Net 4) that uses a Func<T> parameter. But the sample program (3.5) already existed and ran fine so far. But at time of recompilation a dependency of a dependency clashed. Because mscorelib-3.5 had been already loaded. All happens at compilation time.
The only way I could overcome this error was to force uninstall of all nuget packages related and then reinstalling them. Sad but true.
I've just struggled with this error for a while now and finally get around it.
This is how to re-produce it and how I fixed it.
The problem was:
The packages were referenced by Right clicked -> add refernece -> Browse (choose). Then were added again as NuGet packages.
The solution was:
Remove the added references.
Remove the installed packages from .csproj.
Re-install the required packages from NuGet package mangager.
Close Visual Studio and re-open it.
Clean Project.
Build Project.
Note: If you couldn't remove the referenced files (no Remove option on right click) try close Visual studio and re-open it. Or delete or move the dll that were referenced then try again.
For me, I had chosen incorrect project, I was creating a class library project, I had to chose "Class Library (.Net framework)" but I had chosen "Class Library (.Net standard)"
Replacing the same resolved the issue.
The problem was following: my solution had Target Framework = 3.1 and I added a reference to Microsoft.EntityFrameworkCore.SqlServer v 2.0 which is built against the framework .
I had this problem with one of my library projects inside of a solution, after I switched from .NET Framework to .NET Standard. Eventually I just removed the project reference and added it again inside the application project that was reporting the problem. Oddly enough, the only thing that changed was project GUID switching to lower case from the previous upper case.