I have created WPF application solution, added a third-party(cloned git repo locally on my machine) library(Class Library output type) project to the solution, added the library project to my solution:
And then referenced it in WPF Project settings:
When a library throws an exception, I get this in Visual Studio:
I can edit the library project, edit the WPF project, compile everything and it will work. But for whatever reason when an exception is thrown I can't debug the library. How do I fix this?
I fixed Source Not Available error fix by unchecking Use Managed Compatibility Mode Checkbox(checked checkbox causes error to appear) in Tools-Options, Debugging-General:
If someone reads this and knows why Use Managed Compatibility Mode was checked and why I couldn't debug my library because of it, please tell us. It took me few hours of googling, asking people around, and trial and error, until I found out that it was my options(after I decided to reset them to see if it was them). I didn't change this checkbox by myself, I would have remembered it. It was like that from the start. I only export my options from older versions of Visual Studio(Visual Studio 2015 > 2017 > 2019) to preserve code style and other options I like.
Related
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
This question already has answers here:
ReSharper "Cannot resolve symbol" even when project builds
(41 answers)
Closed last year.
I'm currently building an ASP.NET 5 (ASP.NET Core 1.0) MVC application. I'm using Visual Studio 2015 with ReSharper Ultimate 10.0.2.
I currently have a 2-tier layer solution which consists of a Www (web application) and a Services layer. The Www has a reference to the Services layer.
When ReSharper is suspended, the classes within the Www layer are able to invoke objects from the Services layer, as shown here:
However, when ReSharper is enabled, I get the following message: Cannot resolve symbol 'Services', as shown here:
What I've tried:
Clearing the caches from Tools -> Options -> ReSharper Ultimate -> Options -> Clear Caches
Remove the JetBrains folder from %APPDATA%
Restarting Visual Studio 2015
Reinstalling ReSharper
Suspending and resuming ReSharper
Adding and removing references
Rebuilding the solution
Any help is appreciated.
In Visual Studio 2017 I solved in this way:
Close the solution
Delete the ".vs" hidden folder
Reopen the solution and rebuild it
Looks like Jetbrains is aware of this: youtrack.jetbrains.com/issue/RSRP-408661
However, it gave me an idea. I set CopyLocal on the assembly to "true" and now my references resolve.
I had the same issue with v2017.1. Spent some time trying different solutions like clearing cache, suspending and resuming, but no success.
What helped me: I updated to v2017.3.1 (latest on time of writing). So if you facing a problem which you cant fix by simple suspending or clearing cache, consider updating to latest version, probably it was a small bug, and now it is fixed.
For me I got to reinstall MSBuild. Then it worked again.
It seems those "EMIT WARNING" defines come from "xkeycheck.h", a standard include file, which wants to check if a standard data type gets overwritten by some define. It seems that somehow ONLY resharper thinks that this is the case, while VisualStudio itself doesn't have any issues. The emitted warning never appears in a compile, only in resharper. I have this issue in exactly one file, and I couldn't yet find the real cause for it. Ayway, adding a "#define _ALLOW_KEYWORD_MACROS" in this file stopped resharper from running amok.
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 have a project which has a calling structure similar to this:
main project/application
my library code
someone else's library code
my library code
Everything's written in C#, and I have access to 'someone else's library code'. Their code is not included in my project, because it's open source and not my code. I can make debug versions of all the libraries, and I've done so.
That 'someone else's library code (SELC, I guess?) is throwing an exception in a heisen-bug kind of way, and I'm trying to track it down and maybe submit a bugfix to the project maintainer. Problem is, my debugging stack is stopping at my library code, and lists the SELC as 'external' and I can't debug into it. I've copied the pdb files as well as the debug version of the library into the debug directory of my application, and still no luck; I can't seem to debug into their code, and I can't step into it at all.
Once upon a time, back in vs6 days, I could do this-- have two different projects open at the same time in two different environments, and have the debugger trace across dll boundaries from one project into another. I'd assume that functionality remains, because it's just so dang useful.
Any suggestions?
I've looked for this answer but not found it, so if this is a dupe, just let me know where to look.
Do you have "Just My Code" turned on in Visual Studio's debugging options?
If you have the sources (as i read from you), you can make an project with their source code, and then add the project to your solution.
In visual studio the project in .csproj file , and solutions in .sln file.
I am using a third-party DLL. For some particular cases, a function in the DLL is throwing an exception. Is it possible to debug the DLL in the Visual Studio?
After the answer from Andrew Rollings, I am able to view the code, but is there any easy way to debug through the code in Visual Studio?
If the DLL is in a .NET language, you can decompile it using a tool like .NET Reflector and then debug against the source code.
Or you could ask the vendor if source code is available. That's probably the easiest way.
Building on Andrew's answer, you just treat the decompiled source code as a new library within your project and set breakpoints in the source. Remove all references to the 3rd party DLL so that it is the decompiled code that is executing.
Other things:
You may be breaking the law by decompiling the code, or breaching a licensing agreement with the 3rd party vendor. Make sure to review this with someone.
You will want to make sure that you remove references to your decompiled version if you are shipping to other developers, or checking into a larger source tree. Easy to forget this!
There are two methods I've come across:
1) Accessing the DLL project from the using project.
This involves building the DLL in a separate instance of Visual Studio and then accessing the DLL through a different project in Visual Studio (this assumes you have the source code).
There a number of ways to accomplish this:
You can add Trace.WriteLine
statements in the DLL that will show
up in the 'Output' window in Visual Studio.
You can add System.Diagnostics.Debugger.Break() statements to the DLL code. When
running the calling project in Visual Studio,
program execution will stop there.
From here you can add access the
call stack (including all function
calls in DLL itself) and set break
points (although the icon for
the breakpoint will appear disabled
and the hover text for the break
point will read "The breakpoint will
not currently be hit. No symbols
have been loaded for this document").
If the DLL is throwing an exception (which you can see from
the 'Output' window if the exception
is caught and handled by the DLL)
you can tell Visual Studio to always break when
that type of exception is thrown.
Hit Ctrl + Alt + E, find the type of
exception being thrown, and click
the 'Throw' column for that
exception. From here it is exactly
as if you had used
System.Diagnostics.Debugger.Break()
(see above).
2) Attaching a using process to the DLL project.
This involved hooking the Visual Studio debugger into a running process.
Open the DLL project in Visual Studio.
Run an application that uses the DLL (this
application can't be run from
another instance of Visual Studio since the
process will already have a debugger
attached to it).
From here you can add break points and step through
the DLL code loaded in Visual Studio (although
the break point will appear disabled
the same as in method 1).
Something that has worked for me with debugging a couple of third-party libraries as well as .NET itself is WinDbg. It is an awesome debugger from Microsoft that I have used to troubleshoot some sticky problems that were occuring deep inside the framework.
You need to use the Son of Strike (SOS) extensions if it is a managed DLL. It can debug native also. You will need to know a bit about callstacks and assembly/CIL instructions to be good at using it. You should be able to determine the exception and what is causing it. We have used WinDbg/SOS to find for instance that in HttpWebResponse, if you are using Gzip compression to download a page and the server returns a bad Gzip header, .NET runs the decompression in the threadpool and a crash will take out your process. Happy debugging.
One more option we should mention here is dotPeek 1.2 (a free decompiler from creators of ReSharper). Here is a nice post describing how to configure VS symbol server and dotPeek 1.2 to debug decompiled code from VisualStudio: http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program
As Cesar Reyes mentioned in Stack Overflow question Visual Studio - Attach source code to reference, ReSharper 5 (and later) has this capability.
.NET Reflector 6 comes with a Visual Studio Addin that lets you use Visual Studio's step-through-debugging on assemblies that you don't have the source code for.
Have a look at this blog post:
http://www.simple-talk.com/community/blogs/alex/archive/2009/09/22/74919.aspx for more details.
This is still a very early build. So no guarantee that it'll work, and it might break your visual studio configuration or project configuration. Make sure you have backups (or source control) for any projects you use this on.
Download here:
http://www.red-gate.com/MessageBoard/viewforum.php?f=109
I thought .NET Reflector got some debugging plugins. That'd be a so much better idea because decompiling and recompiling code generally fails, and you need to do so many changes in the code to fix it.
Give .NET Reflector debugger a try. It might help you a lot.