We Keep Coding

Unity: Visual Studio loses DLL reference after Unity compiles code

I am using the System.Compression.ZipFile.dll in a Unity project, and have added the reference to both the the Visual Studio project and within the Unity Editor, and the code compiles and runs as expected without issue.
However, whenever Unity compiles the code, the DLL reference is removed from the Visual Studio Project.
As a result, compiling within Visual Studio afterwords will have namespace errors. These errors are only in in Visual Studio, as the Unity editor does have the reference when it actually compiles the code.
These errors are fixed by re-adding the DLL reference to the solution. I would like to stop the errors from showing up in Visual Studio, as they are rather annoying.
How do I prevent the reference from being removed from the Visual Studio Project when Unity actually compiles the code?
If it helps I am using Visual Studio Community 2015, and the Unity Editor 2018.2.14f1, on Windows 8.1, with .NET version 4.7.1
EDIT:
My mcs.rsp file contains: -r:System.IO.Compression.FileSystem.dll
based on a unity forum thread. This is interesting as it is not the expected DLL, and yet it still works.
Adding -r:System.IO.Compression.ZipFile.dll will cause:
error CS0006: Metadata file `System.IO.Compression.ZipFile.dll' could not be found.
The relevant errors are:
CS1069 The type name 'ZipFile' could not be found in the namespace 'System.IO.Compression'. This type has been forwarded to assembly 'System.IO.Compression.FileSystem, Version=4.0.0.0, Culture=neutral, Consider adding a reference to that assembly.
Error CS0006 Metadata file ProjectFolder\Temp\bin\Debug\Assembly-CSharp.dll' could not be found
Unity is correctly configured to use .NET 4.x

The behavior you are getting is expected.
Let's go through the official way to achieve what you're looking for:
Copy your DLL in Assets directory, optionally, with its associated XML for IntelliSense, and the PDB file so that Unity generates an MDB file out of it
Unity rebuilds the project and the generated Visual Studio solution
Since step 2 re-generates the Visual Studio solution, every customization you've done to it are lost, exceptions for manually added existing projects for being able to step through them when debugging your game.
Note that nowhere in the official instructions you are expected to add references to the generated projects, it's done automatically and manual changes are lost anyway as laid out in previous paragraph.
But you are getting errors, right ?
It's hard to tell without more information.
Suggestions:
1.
Try the official instructions and if it doesn't work, edit your question to add the relevant errors so people can further try to help you.
2.
Do your DLL matches the framework version of Unity ?
In some cases it can produce funny errors otherwise.
When I look at the contents of System.IO.Compression.ZipFile, it's only for .NET 4.6:
Do your player settings match .NET 4.6 ?

This issue happens when you use some of the new features in C# 7 or C# 8.
In my case, I was working on an older project, built on .NET framework 4.6 and switched some using blocks to simplified using statements. E.g., instead of
using (var resource = new ExpensiveStuff())
{
//whatever
}
I did:
using var resource = new ExpensiveStuff();
//whatever
The compiler silently allowed me to do this but the next build failed with the CS0006. It took me an hour to figure that out. I was about to re-install my Windows...LOL

Visual Studio 2015 fails to evaluate variables when two versions of assembly are loaded

My .NET application can load multiple versions of the same assembly into memory. Assemblies are not signed but every time new copy of assembly is complied and loaded it automatically gets a new assembly version (in minor part). I do not have any issues with types since instantiation ob objects is under by control, so I know from which assembly the object is created.
This was working ever since VS 2003, but with the latest VS 2015 the debugging of this scenario is broken. All works fine while only single version of assembly is loaded into memory but whenever second version is being loaded all Locals/Watch windows become empty. And trying to evaluate any expression in QuickWatch gives a compiler exception "error CS1704: An assembly with the same simple name 'MyAssembly' has already been imported. Try removing one of the references (e.g. 'MyAssembly.dll') or sign them to enable side-by-side."
Here are screenshots of the same application with attached debuggers from VS2013 and VS2015 (when two assemblies are loaded):
VS2013 Debugger:
VS2015 Debugger:
And the selected parts from loaded assemblies list:
So this makes debugging with VS 2015 almost impossible.
Since originally this is a compliler error (which to my belief is used under the cover of VS 2015 debugger) internet search is not very useful. Here is the only link related to Debugger problem that I was able to find:
Visual Studio Debugger Failing to inspect variables. The difference to my case is that there having two assemblies in memory was a mistake while in my case this is an intent.
So now I am thinking on my options.
Of course, ideally I would like to have some patch to VS 2015 that will fix the issue. But being realistic I am not sure this will happen.
Signing assemblies (as compiler suggests) is not an option since assemblies are generated on clients' machines and it is not possible to provide them with a key for signing.
I could try to play with AppDomains to see if debugger could handle the case when assemblies are loaded to different domains. But even if it could, this would be quite a huge (and unplanned) change to my appliction.
So may be anyone could suggest some more ideas? Thnaks.

I've found a workaround for this problem. There is an option in Visual Studio "Debug - Options - General - Use the legacy C# and VB expression evaluator", enabling it restores previous debugger behaviour.
This option is described in VS 2015 Known Issues for different debugger issue but also works for described case.
I also filed a bug to Microsoft. I do not believe they will do anything about it, but here is the link just in case.

Assuming this is an option in your situation, you could try to rename the class or namespace before loading the assembly.
There are libraries that can modify assembly files: http://www.codeproject.com/Articles/20565/Assembly-Manipulation-and-C-VB-NET-Code-Injection
This of course assumes that you are loading the assembly and types at runtime.

Cannot define a class or member that utilizes 'dynamic' because the compiler required type 'System.Runtime.CompilerServices.DynamicAttribute'

I'm trying to run a .NET MVC application on my local computer that I got from GitHub.
When I hit run on Visual Studio, everything complies and a new browser window opens with the error:
CS1980: Cannot define a class or member that utilizes 'dynamic' because the compiler required type 'System.Runtime.CompilerServices.DynamicAttribute'
The compiler section in the same window, shows the following error:
I've checked on google and this seems to be the same error.
This guy was using a dynamic type himself, on the other hand I'm not using any dynamic type, this is being auto generated by .NET's compiler, and I'm using .net 4.5 which should has support for dynamics.
I tried to apply the same solution (Changing all System.Core references to 4.0)
but the thing is that all of them are version 4.0 already.
Do you have any idea how could I resolve this?

I had a similar error on a project I was trying to migrate. Try re-targeting the framework of the project back a version or two, and once you find a target version where you do not get the error, re-target back to the version you originally had trouble with.
I was getting the same error on a website project targeted for 4.6.2 that was referencing some older libraries, re-targeted it back to 4.5.1 and that resolved the error. I immediately re-targeted back to 4.6.2 and did not encounter the error again.

I had this same issue, but none of the answers here solved it, but did point me in the right direction. I think I didn't update the .NET version on my machine to the newer one. After installing it, I rolled back the targeted framework (as was suggested), retargeted the newer framework, and did a few extra things also:
Reinstalled ALL packages by running this in the package manager:
update-package -reinstall
I also compared my project to one that was working for 4.5 and did this:
Opened my project file and removed all "BCL" related elements.
Uninstalled all "BCL" packages in the NuGet package manager for the project (guess it's not needed moving to 4.5+...?)
Removed an old package version of System.Net.Http, which did not get updated for some reason (see web.config - versions should show oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0").
Have to restart VS.
Rebuild solution.
Error is now gone. ;)
One other thing I did to resolve some other errors was to clear the component cache by deleting all files in here:
C:\Users\{USERNAME}\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache\
[rant] Wasted a whole day with all this. Thanks to MS for stealing one more day of my life fixing senseless issues that should never be. Every time I upgrade I always get a wonderful surprise, and a lovely game of fix the red herring. Would it not hurt to detect these conflicts for those upgrading old projects? Perhaps better error traces when things go wrong? I doubt it would be that difficult. Perhaps even something like AsmSpy, but more advanced, built in to VS? [/rant]

Saw this in VS 2019. I excluded and re-included the problematic file (in my case _Layout.cshtml) and that fixed the problem.

I got this error suddenly a couple days after updating to VS2015.3 using 'traditional' MVC app (not new .NET Core / vNext app).
Turns out this error can be a complete red herring.
Make sure:
You haven't got any other errors at all
You've checked the output window for any errors that don't show in the 'Output' window.
Make sure you don't have any conflicting references
In my case I had a typescript error that was causing an error and for some reason triggering this weird 'red herring' dynamic error too.
My fix was to go into the .csproj file and update the typescript tools version to 1.8 (need to unload project and edit by hand). As I said this is unrelated to the error, but I mention the specifics because someone else may end up with this same problem.
I believe that 1.7 didn't accept 'None' for the typescript module system whereas 1.8 does, hence the error.

Adding a reference to System.Dynamic.Runtime did it for me.

I hesitate to write this as an answer, but for me the error appeared in a .cshtml file. I closed the page, rebuilt, and the error vanished. Always best to try the simple things first.

I had the same error, there were just 2 unused tables of my databaseset that I had to delete. I wonder why it worked when I manually change sth in an auto-generated code work but after deleting, it worked.
So be aware that such inconsistencies can also cause this error.

My solution was to correct the version of MVC in web.config under Views folder. E.g. the project referenced MVC assembly version 5.2.2.0 but in the Views/web.config file was version 5.2.4.0 (see image).
Image

Tried a few other answers with no luck, but the overall consensus appears to be that this some sort of issue with cached build artifacts or compiler state or something. Here's what worked for me:
Delete the problem .cshtml file, watch error disappear
Open source control and revert the deletion

This error will come because of the different versions of your Sitecore.Web.Mvc.Dll in solution reference folder(Project name->References->Sitecore.Web.Mvc->right click and check properties) and the version of Sitecore.Web.Mvc.Dll in Web.Config in views Folder.
For solving this error you have to make sure that the version of Sitecore.Web.Mvc.Dll is same in both folders.
Thanx.

For my case, I fixed to run the command line "update-package -reinstall" on the Package Manager Controler.

My problem was in the _Layout.cshtml.
None of the solutions above did the trick for me. I am using VS2017 for this project, upgraded an ran into the same message.
I had commented out a 2 lines in 1 comment #* *#
My solution was to comment out each line separately. What a mystery!
A few hours lost on this.

Weird: C# Type or Namespace name could not be found - Builds successfully

I have a weird error showing up in my project when it is open in the VS2012 IDE. Everywhere where I make use of another referenced project it suddenly says "Type or Namespace name could not be found". And by "says", I mean it has the text underlined in red with the error when I hover over it. The intellisense doesn't work for that code. BUT (and here's the weird part), the errors do not show up in the error console and the project builds and runs fine.
I can even debug and step through the code and it works perfectly fine. So at runtime the project is referenced fine but at design time the IDE can't find it. This worked for the past 2 weeks, and only then suddenly went a little bonkers. It's really annoying because I am rubbish at coding without intellisense!
Has anybody ever seen anything like this or have any suggestions?

I had this. I referenced assemblies whose "Target Framework" were set to ".Net Framework 4" in the "Application" secion of the projects properties. I changed this to ".Net Framework 4.5" not just in the referenced assembly's project but also the project I was building and it worked. Give this a try.

I have found this is a known problem with VS2012. Check to see how you are building, 64 bit or 32 bit. It won't work with 64 bit but it will with 32 bit. It will say things are missing and design will not work, however the program will run fine. I have heard the new VS update that hasn't been released yet will fix it.

Manually delete all the references to the libraries of the other projects and re-add. Intellisense rebuilds whatever it needs at that point and doing this has helped me in the past.

Another source of this problem is a solution with multiple projects containing code for the same namespace. The compiler can handle this. Intellisense won’t.

Related to a couple other answers here, I had a "Data" project using a "Data" namespace. Built fine, but just started recently showing errors from intellisense (even though it continued building fine.) (VS 2015.)
I fixed this by changing my "Data" project and namespace to "MyCompany.Data".
Oddly, the problem didn't seem to show up until recently, but making the change did fix it. Presumably there was a conflict in namespace with another project or reference, which can build fine, but intellisense can't handle.
You can change this in the Application tab of Project properties. You can also open up an EDMX diagram, right click, choose model browser, choose the second collapsable item in the model browser tab, hit properties, and there you'll find the Namespace option for generated Entity Framework entities and contexts. (Similiarly, if you modify an Entity Framework Model's namespace, you might also need to change the related connection to match [in Web.Config for ASP.Net and MVC.])

Make sure that there is no class with the name same as Project default namespace.

make sure that you don't reference .net framework 4.5 projects in .net 4 projects!

Examine your .proj files in a text editor and make sure the paths to your references are correct.

This can also happen if you set the Build Action to "None" on the referenced file and forget about it.

I had the same problem, where it would build and run fine, it just would always show that error and I couldn't use intellisense with the class.
I actually used the automatic method of creating the class in a new file to resolve the issue, then just copied the code over from the real class. I deleted the old file, renamed the new file, and now it works.

Get Visual Studio to highlight Razor syntax with a custom host factoryType

Here's the scenario, I've extended MvcWebRazorHostFactory so I can do a little bit of extra view magic at build time. The exact magic doesn't matter.
The registration in my ~\Views\Web.config looks like so:
<host factoryType="StackExchange.MyNamespace.MyFactory, StackExchange.MyNamespace" />
There's to the appropriate assembly in the project, a copy of the assembly in a \lib folder, and I've confirmed that it's copied to \bin as expected. Furthermore, the actual view magic does happen when views are built so ASP.NET itself is actually finding everything.
What doesn't work in Visual Studio (2012)'s Razor Syntax Highlighting.
Above is a snapshot of how the syntax highlighting fails. As a rule, anything not in a namespace directly #using'd cannot be found (and thus gets the red squiggly underline) and the #model directive doesn't works. This points to some trouble getting at our automatically included namespaces in the Web.config.
The tooltip for the error on #model is "The name 'model' does not exist in the current context".
Through trial and error I've narrowed the root cause to the above host config section, although we have some other tweaks around Razor (a custom pageBaseType for example) it's that one line that breaks everything.
Things I've tried thus far:
Strong naming the assembly
Installing the assembly in the GAC
This page hints at this being necessary.
When strongly named my ~\Views\Web.config ended up looking like so:
<host factoryType="StackExchange.MyNamespace.MyFactory, StackExchange.MyNamespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b61d663b67b05bd2" />
I checked the Version, Culture, and PublicKeyToken against the GAC using "gacutil -l".
I suppose one other possible point of failure is the GAC itself, as there are ton of .NET versions on my box. Both the assembly and the web site are built with .NET 4.5 (both referencing MVC 4, Razor 2, and so on). The path to the gacutil I've been using while debugging is Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe.
Occasionally during my winnowing to a root cause I'd get an error message to the effect "StackExchange.MyNamespace.MyFactory could not be found" on the first line of a view. The underline would be in the "Other Error" color (Purple in VS2012 Dark Theme). I could not reliably reproduce that, so I can't get a screenshot.
So my question is, does anyone know how to get Visual Studio (2012 again) to properly handle Razor Views with a custom host factory?
My current best guess at a fix is doing some really hacky Web.config replacements so I have one config while editing and another while debugging. Really not a fan of that idea though.
It seems like this should work, and that Visual Studio is just having troubling finding something it needs. I just don't know what that is.
Update after some more experimentation.
I've got more developers to reproduce that it's the <host pageFactoryType="...">, including in a vanilla MVC4 application (the above examples are, somewhat obviously, from the StackOverflow solution; which might have had some cruft).
We have found a work around though, it's to buy a ReSharper license. Not a great (or cheap) work around, but a work around none the less.
With ReSharper installed everything works with one caveat. If you have a custom <pages pageBaseType="..."> registration the type must be in the same project, or you don't get intellisense for #this.Model reference (the #model directive works though).
More updates.
Looks like a no-op HostFactory (one that extends MvcRazorHostFactory but doesn't override any methods or contain any other code) works fine if you strong name it and install it in the GAC. I believe I was using the wrong GAC when testing that earlier, but (with some outside prodding) was able to get it working using the explicitly x64 gacutil.
Now the trouble is figuring out what's wrong with my particular host factory; more details coming as they're discovered.

After some discussion with Microsoft, we found the root cause of this problem.
As usual, it was my code.
The root error was an MVC3 reference in the custom factoryType, despite the project (and everything around it) being MVC4.
To sum everything up, to get Visual Studio IntelliSense working in .cshtml files with a custom <host factoryType>:
You must strong name your assembly
You must install the assembly in the GAC
We still debug and deploy against a local copy, but VS will look in the GAC
You must have all the right references*
Be aware that you'll need to restart Visual Studio after installing into the GAC, simply reloading the solution is not (usually) sufficient. We've also found that some (but not all) ReSharper installations will need their cache's cleared, to be on the safe side clear the cache.
One minor trip up when adding a reference to an assembly that resides in the GAC is the Visual Studio won't copy it to your output directory by default, this may work for you but caused problems for us. You can change this in the properties of the reference.
Also, Visual Studio will give you a number error messages (the "Other Error" purple underline I was unable to reliably reproduce earlier) if your custom factory throws any exceptions; except perhaps in it's constructor (that seemed a little inconsistent).
Where you get no help is the case we were in, where the type itself has serious issues. It was just a coincidence that things worked at runtime (the interfaces we're playing with didn't change between MVC3 and MVC4, and weak naming did the rest).
*If you're like us and have MVC beta 1 through 4 installed, be aware of the PEBKAC in this step.