Visual studio wont recognize certain packages (Entities, and TMPro, to name a few) and it gives the error: The type or namespace name could not be found; but everything compiles fine. I know there are already many questions and answers related to this problem, but so far none of them have worked for me.
So the way I downloaded these packages was by using the Unity Package Manager, so this makes things even more confusing because I installed other packages the same way, and they are recognized no problem.
So far I have tried:
Checking the target framework of the packages and the project (all are .NET Framework 4.6)
Deleting the Library folder
Checking my Unity version (2019.2.0a11)
Some extra notes:
I've had this issue for a long time now (with TMPro to be specific; for about a year) ever since downloading it from the Package Manager in one of the 2018.X versions
In other Unity projects, which are using various versions, give the same result. This leads me to believe it is something to do with my visual studio.
The Entities package shows up on the side, see picture below
I uninstalled Visual Studio 2017 installed Visual Studio 2019 and it fixed my problem. I suspect re-installing like others suggested may have worked too.
Related
It's been a while since I've gotten into nuget hell but I'm back to this again...
I'm not exactly sure what caused this issue other than I did a visual studio 2019 update before I left on Friday. Now today, I've been fighting an issue where my library won't compile due to "Must Use PackageReference".
I've found a few articles out there on this but nothing that seems to specifically address this problem.
This issue could also be due to accidentally adding some .netcore librairies (entity framework .core) to the .netframework library. I had a hard time removing those libraries using nuget.
I also tried to reload the nuget library by:
nuget-package -reinstall Microsoft.Windows.SDK.Contracts
That reloads the package ok, but when I recompile the library the error "Must use PackageReference" comes back again.
In the output window I have this when compiling:
...\path...\packages\Microsoft.Windows.SDK.Contracts.10.0.19041.1\build\Microsoft.Windows.SDK.Contracts.targets(4,5): error : Must use PackageReference
I'm not even seeing this referenced in any of my source files so I'm not sure I even need it. However, I can't uninstall it as it seems to have octopus tentacles in numerous other libraries.
What am I running into here and how do I get this resolved?
My fix was to convert the projects to PackageReference as seen here: https://learn.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference The problem went away after doing this and I haven't seen it since. Still a little uneasy on why this happened... But I don't have time to dwell on it.
I've been using visual studio code as a second display (with visual studio as the first) to view/edit code mostly JavaScript since you can right click/format the code with easy.
But I recently took to time to study how it's c#/asp.net core debug functionality has evolved and it seems it has become even more easier to start whipping debug in no time.
But there is one thing I haven't figured out and whether it's even possible. That's it managing nuget packages. Visual studio offers a nice package manager ui to view installed packages and which packages might need a version bump.
It's there an alternative for visual studio code other than browsing the nuget site and checking which of your referenced packages have updated and editing the .csproj manually or running dotnet add <project> package ...?
This is probably not relevant anymore, but for anyone else also searching for something like this, there is a pretty handy extension for VSCode called Package Manager GUI here.
The Restore step fails in my build definition with this error:
error NU1100: Unable to resolve 'AutoMapper (>= 6.2.2)' for '.NETCoreApp,Version=v2.0'.
This is in a .NETCoreApp 2.0 that is using AutoMapper. Restore succeeds locally in VS 2017. Locally I am using dotnet sdk 2.0.0, and nuget 4.3.1. On the VSTS (cloud) server, I am specifying the latest nuget version, 4.5.0. I have tried many other versions, including 4.3.1 with no success.
I know there is an older, similar question here, but that was never answered satisfactorily, in my opinion.
If I look at the meta data in VS, at the top of one of the Automapper files I can see this:
Assembly AutoMapper, Version=6.2.2.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005
// C:\Users\randyg.nuget\packages\automapper\6.2.2\lib\netstandard1.3\AutoMapper.dll
From this you can see it's taking the netstandard1.3 version, which is correct. I'm wondering if the nuget on the build server is looking for a netcoreApp2.0 folder, rather than the netstandard1.3 folder? Following this theory, I tried adding this to my .csproj file:
<AssetTargetFallback>$(AssetTargetFallback);netstandard1.3</AssetTargetFallback>
My theory was this would tell nuget to look for a netstandard1.3 version of automapper if it couldn't find a netcoreapp2.0 version. However, this didn't have any effect. I later read that behind the scenes this fallback is already added automatically.
If anyone has any ideas I would greatly appreciate it. I'm pulling out (what's left of) my hair on this, as this is the only package giving me trouble, and it's a critical one for my project.
On the build server I'm using .NET Core sdk 2.0.3 as well, if that matters.
This is how I solved this: since it seemed it might have to do with my target being netcoreapp2.0, I tried adding an additional 'dummy' project to my solution, with its target = netstandard1.3. In this configuration, the restore/build succeeded. I thought I would have to maintain this dummy project for this purpose, until I tried deleteing it and now the netcoreapp2.0 solution still restores fine without it. I can only assume something was corrupted in the TFS build server NPM cache (even though I had tried checking the box to disable that cache), and once I got it to succeed once, it has cleared up whatever the issue was.
I am using Roslyn for application scripting via Nuget Package Manager. Setup should be rather simple. Create new project and, in Nuget manager, add Microsoft.CodeAnalysis.Sripting package. After couple of confirmations you are ready to go.
Next step should be checking for installed packages update. Currently, there are 5 updates that are shown after initial installation. Again, it is pretty straightforward to do this.
However, immediately after the update, two of those packages show yellow triangle in Reference node of the project.
I have tried to resolve this following SO and other hints but nothing helped me so far.
At the end, I have installed new VM with Windows 10 Pro (with all updates) and VS2017 Community Edition. After that new Windows Forms project (.net 4.6.1. based for x64) was created and scripting package is added. Unfortunately, yellow triangles are still there (after update).
Problematic packages are System.ValueTuple and System.Security.Cryptography. X509Certificates.
Also, after cleaning and rebuilding the solution, a number of warnings (MSB3836) - explicit binding redirect on "System..." conflicts with autogenerated binding redirect.
Solution to this problem might shed a light on problem with more complex solution that I stumbled upon after migration to VS 2017.
So, what is the reason for such behavior? Remember, this happens on new installation of OS and VS with simplest project possible.
Visual Studio 2017 Communnity Incorrectly Updates Roslyn Scripting
I got the same result with you steps. This issue only occurred on the Visual Studio 2017 not Visual Studio 2015. That should have some issue with package Microsoft.CodeAnalysis.
To resolve this issue, I would like provide you a workaround:
Update packages "System.ValueTuple" and "System.Security.Cryptography. X509Certificates" first, then update other packages.
It works fine on my side, you can check if it works for you.
In order to track this issue, I have create a new issue on GitHub:
https://github.com/dotnet/roslyn/issues/22290
If you have additional information to add, you can add comments below that issue. And you can check the feedback from this link.
I'm using Visual Studio for my Unity project. (Unity is using mono framework, NOT .net). I'm using a database so I have to use System.Data.dll in the project which i'm keeping in Assets/Plugins folder:
As you can see Visual Studio has problems seeing System.Data library. So I'm hardcoding:
And some more red lines:
Surprisingly, I have no errors in Unity and the code is actually working:
I also have this annoying yellow icon in VS:
Can you help me in forcing Visual Studio to see System.Data library please?
The System.Data.dll, System.MySql.dll and System.Drawing.dll should all placed in the Assets folder not in the Assets/Plugin folder. Making these changes get ride of the error.
EDIT:
Adding System.Data.dll to the Assets folder should work but is failing silently. Digging deeper into this, I got this error:
The primary reference "System.Data" could not be resolved because it
has a higher version "2.0.5.0" than exists in the current target
framework. The version found in the current target framework is
"2.0.0.0".
So, the System.Data.dll version is different from your target framework and that is the problem. You need another version of System.Data.dll that is the-same version of your target framework(2.0.0.0).
You can get a compatible version(2.0.0.0) from:
C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Unity Subset
v3.5