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
Related
I am working on a small project involving a wpf-based UI program when I come to a intellisense problem. It constantly complains that several identifiers (class/method/property) cannot be found, and most of those are from another assembly. Similar issue has been asked by many other users of visual studio:
WPF assembly reference missing - project still building
Type or namespace cannot be found, when reference does exist
Getting "type or namespace name could not be found" but everything seems ok?
If the promble only happens on types in referenced assemblies I might just overlook it. But now even some types in the same assembly are determined 'missing' by intellisense. Today I created a new custom Window in this wpf project, and visual studio auto generated code for further use as follows:
public partial class ReceiveTest : Window
{
public ReceiveTest()
{
InitializeComponent();
}
}
Then intellisense told me that identifier 'InitializeComponent' cannot be found, and every control this window owns cannot be found either. This is really upsetting since it makes intellisense completely useless. Normally these 'missing' identifiers are declared in FileName.g.i.cs and managed by visual studio itself, however it seem visual studio somehow failed to recognize it.
Now I have done everything I can including solutions given in above links but failed again and again. Could anyone explain this problem and show me a way to solve it? I would be very very grateful.
P.S. I am using visual studio 2017 and PowerTool addon
Upgrading Test project from 2010 to 2017
Following this up on a recent problem with a test project on VS2017 after upgrade from 2010. Tried everything to get rid of the squiggly red and they wouldn't go.
Problem was that 'namespace.zone.section' had 'namespace' not found when it was there and seen by intellisense etc (and in some cases 'zone' or 'section')
Deleted sou files
Deleted project files
Deleted the references
Reapplied all after clean, restart, restart
server and all the above.
Still problem persisted.
So I deleted the test project (imported form 2010) recreated the project in 2017, copied all the original test classes into new project, added back all the other projects (supporting the tests), added moq etc back in. Only took about 20 mins.
And ... compiled and worked.
Conclusion was that the original project file (test project) had something in it that didn't get upgraded and screwed it all up. Anyway it is all fine now.
I post this so you don't have to wast your time.
I'm debugging a .NET 4.0 application in Visual Studio 2015. My application builds and runs fine, but when I try to edit and continue while running under the debugger, regardless of what changes I make or where I make them in my main project, I get a dialog that says:
Edits were made which cannot be compiled. Execution cannot continue
until the compiler errors are fixed.
As an example of the sort of change I'm talking about, I've tried adding this line in various methods:
Console.WriteLine("foo");
When I look in Visual Studio's Error List pane, I see only one error, CS7038, with the description "Failed to emit module '<my app name>'." No filename, line number, or character is given. There are no squiggly red underlines in my code. If I stop the running application, build with the changes, and run again, everything builds and runs just fine. So there seems to be some discrepancy between what the build-time compiler and the edit-and-continue compiler consider acceptable.
Does anyone know of a way to get more information about why the compile fails in Edit and Continue mode? I read something about attaching to and debugging the VBCSCompiler process, so I tried that, but even with all exception types set to break when thrown, the attached VS never broke.
I'm not sharing any code because this isn't a question about my code but rather about strategies for finding out what the Edit and Continue compiler thinks is wrong, and for all I know the source of the compiler error could be anywhere in my entire project.
Edit:
As mentioned in the comments, I was able to attach a debugger to Visual Studio and break when an exception was thrown upon clicking "Continue" after editing code. The exception was a System.NotSupportedException with the following message: "Changing the version of an assembly reference is not allowed during debugging". It listed the name of the assembly in question, which was a small VB.Net project used by my application, which is mostly in C#. I'm trying to build up an MCVE to submit to Microsoft, but currently I'm unable to reproduce the problem in a smaller solution with just one VB and one C# project.
Edit 2:
I've found a workaround and self-answered the question in case anyone else ever encounters this weird problem, but I'm reserving the "Answered" check mark for anyone who can explain what's going on (why the compiler thinks the version number of the referenced project has changed during the edit).
I found a workaround for the problem, but I don't fully understand what was going on. In the VB.NET project whose assembly version the Edit and Continue compiler said was changing, there was a file called "AssemblyInfo.vb". That file contained the following line:
<Assembly: AssemblyVersion("3.0.*")>
The assembly version can also be set in the Project Properties, via the "Assembly Information" button in the Application tab:
When I removed the AssemblyVersion line from AssemblyInfo.vb, my Edit and Continue problem went away. At first I thought this was because the fields in the Assembly Information window were saved to a different file from AssemblyInfo.vb and there was some conflict between the two, but now I see that the Assembly Information window is just a handy way to edit AssemblyInfo.vb: if I delete the line in AssemblyInfo.vb, it gets cleared in the Assembly Information window.
After some more experimentation, it appears that the asterisk in the version number is the culprit. If I fully specify the assembly version, my Edit and Continue problem goes away. And the referenced project has to be a VB.NET project. I tried the same setup with a C# project, and I could Edit and Continue just fine.
This appears to be very much an edge case, and I'll submit a bug report to Microsoft, but in the meantime I'd love to know what is actually going on with the compiler--why it's getting two different assembly versions of an assembly that really shouldn't need to be recompiled during the debugging.... If you have a good explanation for what's happening, please add it as an answer.
Edit: here's the bug report I filed.
This happened with me in a .net 4.8 app with Visual Studio 2019.
I have a mix vb and cs projects, here the problem appears when a vbproj references a csproj that uses the wildcast operator '*' to specify the version of the assembly.
As commented above by #Wai-Ha-Hee, the wildcast uses the current time, I belive when VS rebuild the application to apply the edits you have made, the version of the assembly changes causing the error.
In assemblyInfo file (of the project present in error) Change:
[assembly: AssemblyVersion("1.0.*")]
To:
[assembly: AssemblyVersion("1.0.0.0")]
It Solved for me.
An important thing to say is the use of wildcast '*' make the assembly non-deterministic, it means each build produces a different assembly. This has been considered bad practice because build the source code in the same conditions generates different assemblies.
In Visual Studio 2019:
New csproj/vbproj with non-sdk style projects file are generated with:
<Deterministic>true</Deterministic>
And new csproj/vbproj with Sdk style projects file omits this line but assumes deterministic as default too.
I recommend considerate other ways to version the assembly.
More about Deterministic:
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
https://reproducible-builds.org/
One of my C# projects in a mixed solution was .NET Framework 2.0 (while others - both C# and VB.NET - were .NET Framework 4). After I changed it to .NET Framework 4 it began to work.
I have used windows store apps 8.0 in my project and upgraded it to be 8.1. And also upgraded Visual Studio from 2012 to 2013.
First, I got an error that cannot use the Microsoft.VCLibs Version 11.0 and 12.0. So I removed the 11.0 version.
And then I got this errors:
I tried to find some information on the internet, but nothing.
Also when I double clicked on the error it doesn't bring me to the error's spot.
I have tried to do many things, and nothing helped, so I decided to write this post.
Can someone help me resolve this errors?
EDIT:
I am adding some more information, maybe this can lead to the problem:
Solved:
With the help of Hans Passant the errors have fixed. The problem was that I had this duplicate on my resource file:
I did it twice because one is for buttons (that has content), and one is for message dialogs on code behind.
In Visual Studio 2012 this code was working fine, but somehow, not in Visual Studio 2013.
I deleted the row of Cancel.Content and the errors disappeared and it works fine :)
Here is somebody else with the same problem.
I'll just copy Caplan's guidance. Look through the .resw file(s) in your project and look for a duplicated "Cancel" resource. I should note that intentionally forcing a duplicate resource produced another message when I built the program on VS2013:
1>MakePri : error 0x80073b0f: Processing Resources with error: Duplicate Entry.
1>MakePRI : error 0xdef00532: Conflicting values for resource 'Resources/String1'
Same message from either duplicating the resource in the same .resw file and by making a copy of the .resw file and adding it to the project. So Caplan's explanation isn't exactly a slam-dunk. I'd pay attention to other projects in your solution that might also have a resource named "Cancel". A likely scenario when your solution has a dependency on VCLibs, that sounds like you are mixing C# and C++/CX.
I came across this MSDN URL which seemed to be pretty helpful.
2 snippets in particular you could try:
You could actually have a duplicate resource entry in your project file.
Your obj files could have become corrupt, you need to clear out your obj files (although I haven't seen this problem for a while in my
team - it might be fixed in 2008).
If you are using a custom culture, perhaps with the .Net RegisterCulture method, ensure that the culture has been registered on
your computer. If you've reinstalled your OS and installed VS2008 and
you can't build due to this problem it could be because you need to
register your custom cultures before you build. This error seems to
be thrown when msbuild cannot find the culture.
Alternatively:
PS - There is also a Visual Studio 2012 Update 3 available that could possibly help?
Visual Studio 2012 Update 3
I hope this helps.
A similar error can also occur if you update a Nuget package in one project, but not in another dependent project also using the same Nuget package.
i.e. it can be a version mismatch error when referencing different versions of a dependency across two dependent projects.
I don't know if you have tried re-installing VS 2013, I was getting the same error but it was resolved when I re-installed.
In my case, after retargeting a working Win8 App for Win81 App, was UI string. Imho it is correct but soehow the VS2013 has some problems with it.
Locations SomeString
Locations.Text SomeStringForUI
Removing the one of them solved my problem.
Recently i got a similar build exception on my UWP Project
MakePri : error 0x80073b0f: Processing Resources failed with error: Doppelter Eintrag.
MakePRI : error 0xdef00532: Conflicting values for resource 'System.Design/ClassComments1'
I found a lot of information about the error but no solution. It looks like the error must be in the entry application project but it isn't.
In my case the VS integrated automaticly a reference to System.Activities because a made a mistake.
After i deleted the wrong reference, it works fine again.
Got this error in a UWP Xamarin.Forms project when a fellow developer referenced System.Web in a PCL that the Xamarin.Forms PCL references.
For more info:
Add System.Web Reference To A Windows 10 Universal App
I am using the MagicLibrary for a few components. I knew it was written in Visual Studio 2003 and recompiled it in Visual C# Express 2010. It compiled just fine and I could see the library in the folder.
I then created a new project in Visual C# Express 2010 and added the components MagicalLocalLibrary.dll to the Toolbox. They appeared fine with no errors. I put in a control from the Toolbox to my form, and it seemed fine. I then debugged (to see if any errors would occur) and I saw that the reference MagicalLibrary disappeared and I got the error:
The type or namespace name 'Crownwood' could not be found (are you missing a using directive or an assembly reference?)
The thing is that, the reference shows fine under References in Solution Explorer but I can't import it with using or use it in the code (simply is not listed in InstelliSense either) but if i go into the Object Browser and choose "My Solution" it is not listed. I can click on the Reference in Solution Explorer and just change the Copy Local property to True or False, then it will appear in the Object Browser but whenever I debug my project again it disappear.
Any idea why it does this? Thanks in advance.
Check that you are using the .Net 4 framework and not the client profile version
You find that setting when you right-click on your project, choose properties. And under application there is a setting for target framework. If you have chosen the .Net 4 framework Client Profile, then this behavior that you described can happen
I ran into a very similar issue once. In my case the problem turned out to be a missing dependency for the "vanishing" namespace's assembly. What finally gave me the information I needed was the suggestion in this StackOverflow answer to raise the MSBuild output verbosity level. After raising the verbosity setting the IDE should give you a more specific reason why the compilation fails.
I'm trying to include in my XAML some classes which convert values. However, I'm getting the following error when I compile:
Undefined CLR namespace. The 'clr-namespace' URI refers to a namespace 'View.Summary.Converters' that is not included in the assembly.(View\View)
And the XAML it's erroring on:
xmlns:c="clr-namespace:View.Summary.Converters"
Also, here is the outline of my conversion classes/namespace:
namespace View.Summary.Converters
{
class CollapsedIfNegative : IValueConverter { }
class VisibleIfNegative : IValueConverter { }
class ErrorCodeToString : IValueConverter { }
}
I had to remove the guts of the code because the project I am working on is highly confidential.
rebuild the solution and the error will go away.
I just solved this by changing the target from x64 to x86.
Apparently Visual Studio is 32bit process and it's unable to load 64bit assemblies, and if your assembly is targeting x64 platform and you adding some custom control visual studio is unable to load it and throws this message.
If you reference to an external project, you must specify the assembly as it appears in your project's references:
xmlns:mdls="clr-namespace:MyProject.Models;assembly=MyProject.Models"
I figured out what was wrong. Although visual studio showed this as the first error, there were indeed other errors with my coding which prevented the converters from being assembled. Thus, when VS went to find the assembly, it was not there.
some problem with vs2008 designer
do this:
close the designer
rebuild-all (Alt+B+R) the solution
now there wont be any errors.
I was able to reproduce your issue:
I created a simple WF in .NET Framework 4.0. Renamed the xaml file. As part of renaming the xaml file you have to manually rename the workflow runtime name when calling the Invoke on the WorkflowInvoker object. I build the project. I got the error "The 'clr-namespace' URI refers to a namespace 'System' that is not included in the assembly."
How I fixed it:
I open the project property page. For some reason, the target framework was switch from .NET framework 4.0 to 4.0 client version. So, I selected .NET 4.0 and rebuilt the project. The error is not there anymore.
Check that your build configuration has the Project selected for build in your current (Active) build configuration.
I just had this problem after fiddling with the Build architecture (from x86 to x64) and the main wpf project had been de-selected.
I have ran into this issue on a C# WPF project.
It seems to be generated when you closed the project with last attempt with Errors of any kind during your project not even in the relevant Namespace in issue in XAML.
The solution to this is to fix all .CS files (Or exclude the problematic XAML/CS files) to get a running version Rebuild and run.
It took me close to 3 hours to figure that the Debug version that the designer seems to be running on must be faulty. This is why in many cases people resolved this with Rebuild project, but in cases that you have existing code errors in project the issue will not resolve it self since the Rebuild fails to complete and does not replace the designer supported version.
hoped this helps!
Visual Studio keeps reverting back to the odd assembly file paths. Just delete the actual reference file it's referring to and then add it to the project
I had the same error. But apparently, it was just because of the path of the solution that I was trying to build.
My path/directory/folder name contains some spaces.