I added a Nuget library called Mpir.Net, which specializes in manipulating gigantic numbers much faster than the in-built BigInteger class does. When I added it in, Visual Studio 2017 was able to find the DLL, add it into my references, and provide suggestions based on the variables and functions defined in the DLL. Visual Studio was clearly able to find the DLL, unlike many questions on here from people with similar problems.
The problem is that when I run the program, it says xmpir64.dll not found, even though Visual Studio can reference things inside it in the code editor.
I've tried changing the target .NET version to no avail. What is the problem?
As a side note, I'm very new to C# and Visual Studio, so please keep that in mind when answering. Here is a link to a picture of my solution explorer.
Mpir.Net is a wrapper around an unmanaged library (GMP). When it says it's unable to find the DLL, it's because it's looking for the unmanaged one (xmpir64.dll) which is in your project folder (not the managed one in the references, which is the wrapper).
You probably just need to click on xmpir64.dll (and the x32 one too), look at its properties in the bottom right, and ensure copy to output directory is set to "copy always".
As a side note, Mpir.NET does not dispose of its unmanaged resources correctly, so don't be surprised if you have a big memory leak. I don't think I'd use it for commercial code.
Related
What is the use of the "References" list in my visual studio project? Why I can still get my project compiled and run it even though I remove all of the references?
When I create a new c# console project, it has a hello world template program, and the References list contains certain references from .Net I think. I removed all of them and the template program still work, why?
The template program has a bunch of usings that were in the references of the project so I thought if I remove all of them nothing will work, but the project still compiled and ran.
This seems to be a very simple question but I can not find anybody answering that online.
Say you need to create an image processing app. But you don't want to, or rather won't be able to create a JPEG encoder/decoder. So you will find a 3rd party library to do the encoding/decoding. And the 3rd party library needs to be put somewhere so that your project can find it. And that is the References folder (it is not really a folder).
Then you can use the 3rd party library's namespace in your own code. And it compiles. But if you remove the references, it won't because VS won't be able to find those namespaces.
If later you decide not to use this library, you will remove your using statement and all the relevant code. At this point, if you remove the references, your code will still compile because they are not used at all.
Ok to answer my question after some research and tests. There are indeed namespaces I can not reference if I don't add them into the References list, the ones that were still working after I removed references were the ones that are implicitly referenced by visual studio.
I have learned that from the links below.
https://learn.microsoft.com/en-us/visualstudio/ide/managing-references-in-a-project?view=vs-2019
https://social.msdn.microsoft.com/Forums/vstudio/en-US/92a0c975-e350-4d8d-af8e-36ec0ad6c95c/specific-purpose-of-mscorlib-dll-in-net?forum=clr
I've searched on google and here quite a lot for my problem and can't seem to find a solution.
I have this huge solution, one of the projects(let's call it "Main") have reference to two other projects(A and B). Projects A and B have a reference dll from an external tool, it's the same tool, but different versions of it. The developer must have the tool installed in the computer to be able to use it.
Now, Project A uses Tool_v1.dll, and Project B uses Tool_v2.dll. If a developer has Tool_v2 installed, they can build the Main project with no problems, but if he has Tool_v1, the old version, he can't build Project B for obvious reasons.
My idea to solve this(as a developer with old Tool_v1 installed) was to make two build configurations in VS, but just having the Project B's referenced, even if not used, still causes it to be built, thus giving errors when I want to build the solution.
If I simply delete Project B's reference works like a charm, but I wanted to simply choose the build configuration it's and done. Any ideas?
You can create two different configurations, each with specific reference lists/locations.
I have detailed instructions on how to accomplish this here: https://johniekarr.wordpress.com/2013/12/25/configuration-specific-reference-location/1
I'm getting System.IO.FileNotFoundException: The specified module could not be found when running C# code that calls a C++/CLI assembly which in turn calls a pure C DLL. It happens as soon as an object is instantiated that calls the pure C DLL functions.
BackingStore is pure C.
CPPDemoViewModel is C++/CLI calling BackingStore it has a reference to BackingStore.
I tried the simplest possible case - add a new C# unit test project that just tries to create an object defined in CPPDemoViewModel . I added a reference from the C# project to CPPDemoViewModel .
A C++/CLI test project works fine with just the added ref to CPPDemoViewModel so it's something about going between the languages.
I'm using Visual Studio 2008 SP1 with .Net 3.5 SP1. I'm building on Vista x64 but have been careful to make sure my Platform target is set to x86.
This feels like something stupid and obvious I'm missing but it would be even more stupid of me to waste time trying to solve it in private so I'm out here embarrassing myself!
This is a test for a project porting a huge amount of legacy C code which I'm keeping in a DLL with a ViewModel implemented in C++/CLI.
edit
After checking directories, I can confirm that the BackingStore.dll has not been copied.
I have the standard unique project folders created with a typical multi-project solution.
WPFViewModelInCPP
BackingStore
CPPViewModel
CPPViewModelTestInCS
bin
Debug
Debug
The higher-level Debug appears to be a common folder used by the C and C++/CLI projects, to my surprise.
WPFViewModelInCPP\Debug contains BackingStore.dll, CPPDemoViewModel.dll, CPPViewModelTest.dll and their associated .ilk and .pdb files
WPFViewModelInCPP\CPPViewModelTestInCS\bin\Debug contains CPPDemoViewModel and CPPViewModelTestInCS .dll and .pdb files but not BackingStore. However, manually copying BackingStore into that directory did not fix the error.
CPPDemoViewModel has the property Copy Local set which I assume is responsible for copying its DLL when if is referenced. I can't add a reference from a C# project to a pure C DLL - it just says A Reference to Backing Store could not be added.
I'm not sure if I have just one problem or two.
I can use an old-fashioned copying build step to copy the BackingStore.dll into any given C# project's directories, although I'd hoped the new .net model didn't require that.
DependencyWalker is telling me that the missing file is GPSVC.dll which has been suggested indicates security setting issues. I suspect this is a red herring.
edit2
With a manual copy of BackingStore.dll to be adjacent to the executable, the GUI now works fine. The C# Test Project still has problems which I suspect is due to the runtime environment of a test project but I can live without that for now.
Are the C and C++ DLLs in the same directory as the C# assembly that's executing?
You may have to change your project output settings so that the C# assembly and the other DLLs all end up in the same folder.
I've often used the Dependency Walker in cases like this; it's a sanity check that shows that all the dependencies can actually be found.
Once your app is running, you may also want to try out Process Monitor on the code you are running, to see which DLLs are being referenced, and where they are located.
The answer for the GUI, other than changing output settings, was the addition of a Pre-Build Step
copy $(ProjectDir)..\Debug\BackingStore.* $(TargetDir)
The answer for the Test projects was to add the missing DLL to the Deployment tab of the testrunconfig. You can either do so by directly editing the default LocalTestRun.testrunconfig (appears in Solution under Solution Items) or right-click the Solution and Add a new test run config, which will then appear under the main Test menu.
Thanks for the answers on this SO question on test configurations for leading me to the answer.
The reason why this happens is because you either are loading DLLMAIN from managed code, before the CRT has an opportunity to be initialized. You may not have any managed code, be executed DIRECTLY or INDERECTLY from an effect of DllMain notifications. (See: Expert C++/CLI: .Net for Visual C++ Programmers, chapter 11++).
Or you have no native entrypoint defined wahtsoever, yet you have linked to MSVCRT. The CLR is automatically initialized for you with /clr, this detail causes a lot of confusion and must be taken into account. A mixed mode DLL actually delay loads the CLR through the use of hot-patching all of the managed entry point vtables in your classes.
A number of class initialization issues surround this topic, loader lock and delay loading CLR are a bit trickey sometimes. Try to declare global's static and do not use #pragma managed/unmanaged, isolate your code with /clr per-file.
If you can not isolate your code from the managed code, and are having trouble, (after taking some of these steps), you can also look towards hosting the CLR yourself and perhaps going through the effort of creating a domain manager, that would ensure your fully "in-the-loop" of runtime events and bootstrapping.
This is exactally why, it has nothting todo with your search path, or initialization. Unfortunately the Fusion log viewer does not help that much (which is the usual place to look for .NET CLR assembly binding issues not dependency walker).
Linking statically has nothing todo with this either. You can NOT statically link a C++/CLI application which is mixed mode.
Place your DLLMAIN function into a file by itself.
Ensure that this file does NOT have /CLR set in the build options (file build options)
Make sure your linking with /MD or /MDd, and all your dependencies which you LINK use the exact same CRT.
Evaluate your linker's settings for /DEFAULTLIB and /INCLUDE to identify any possiable reference issues, you can declare a prototype in your code and use /INCLUDE to override default library link resolution.
Good luck, also check that book it's very good.
Make sure the target system has the correct MS Visual C runtime, and that you are not accidentally building the C dll with a debug runtime.
This is an interesting dilemma. I've never heard of a problem loading native .DLLs from C++/CLI after a call into it from C# before. I can only assume the problem is as #Daniel L suggested, and that your .DLL simply isn't in a path the assembly loader can find.
If Daniel's suggestion doesn't work out, I suggest you try statically linking the native C code to the C++/CLI program, if you can. That would certainly solve the problem, as the .DLL would then be entirely absorbed into the C++/CLI .DLL.
Had the same problem switching to 64-bit Vista. Our application was calling Win32 DLLs which was confusing the target build for the application. To resolve it we did the following:
Go to project properties;
Select Build tab;
Change 'Platform target:' option to x86;
Rebuild the application.
When I re-ran the application it worked.
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.