We Keep Coding

Debugging System.Threading

Is it possible to debug System.Threading library?
I have a stack trace that looks somewhat like this:
I have followed all the steps I could see on how to debug .NET libraries.
Uncheck 'Enable Just My Code'
Check 'Enable .NET Framework source stepping'
Check 'Enable Source Sever Support'
Check 'Microsoft Symbol Servers' under Symbol file (.pdb) locations
And yet when I try to debug a System.threadin call, I get a file not found page that asks me to Browse and Find the .cs file.
Something like this.
Is it possible to debug System.Threading library? Am I missing any steps?
Edit:
I am not sure its a duplicate. For example, the top solution on the other thread asks me to go to referencesource.microsoft.com which does not even contain System.Threading. This is a question specifically for that library. If nothing else, a valid answer for this might be 'It is not possible to debug System.Threadin' or it is possible but use some other method to do so

Normal scenario:
We can try upgrading to newest .net 4.8 framework, it works for some situations like these two similar issues How to debug System.Web.dll? and Unable to step into PresentationFramework.
Cause we should ensure https://referencesource.microsoft.com/ contains the exact version we're debugging, most of the time it's better to choose the latest version.
But for this one:
Since upgrading to .net 4.8 seems to not resolve this issue(Maybe something I did wrong in the process?).I choose another direction(using local source) but it works in my side.
When we're debugging the .net framework source code, apart from the source server, it will also try to find the source in local directory. So we can download the source code .zip file in our machine and configure the Source File settings for solution.
1.Go https://referencesource.microsoft.com/ and click the Download button in the upper right corner
2.Download the entire source code of .NET Framework as a .zip file. Since my project targets .net framework 4.8, so I download the .net 4.8 package.
(We only need to download the appropriate package corresponding to our project, no need to download all of them)
3.Unzip the .zip file which contains source code and move it to an Location I decide to keep the source code, then in VS IDE=>Right-click solution => Properties => Common Properties => Debug Source Files => New Line(Ctrl-Insert) and enter the path of the Source folder(The Source folder in unzipped folder)=>Apply=>OK.
For me, I put the unzipped DotNet48RTM folder in Documents folder, so the path I enter in the Debug Source Files setting is C:\Users\xxx\Documents\DotNet48RTM\Source
Then I can step into the System.Threading library after I run a rebuild.
In addition: Make sure you've met all requirements mentioned here. You should disable require source files to exactly match the original version option and Empty the symbol cache in Debug=>Options=>Symbols.

Unable to load "lpsolve55.dll" in VS2015 on 64-bits OS

For a project I am working on, I need to solve a mathematical model. I chose to do this using Microsoft.Solver.Foundation and the SolverFoundation.Plugin.LpSolve plugin. Both associated .dll files for these extension seem to work fine, as VS2015 recognizes and references them without a problem and compiles and runs my program without errors.
This is however up untill I try to actually solve my optimization, which needs "lpsolve55.dll" to work. I have downloaded this dll and put it in my project's bin/Debug folder, but for some kind of reason VS2015 just doesn't recognize it. I.e.
I can't reference it by simply browsing to it from my "Add Reference" tab.
It's impossible to (un-)register it via the regsvr32 cmd-prompt application, as it doesn't have any DLL (Un-)registry entry points.
The TlbImp.exe cmd-prompt application can't handle it.
So basically, after discovering the above (after trying the most-common internet solutions), I still feel quite dissatisfied to get the error message while I try to solve the optimization -
Unable to load DLL 'lpsolve55.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The wierd part is also that I have another project in which I solve a similar problem, where there are absolutely no problems at all using lpsolve55.dll....
Some quick facts:
I reference .NET framwork 4.5.2. I have changed it to 4.5 as well as 4.0, but this didn't change anyting.
For as far as I can tell, the bin/debug folder of my projects are identical.
I am working on a fully updated windows 10 OS, 64 bits, while using visual studio 2015.
My question would thus be whether or not some of you have encountered a similar problem and if you were able to solve it in some way.
Highly appreciated!

After some careful analysis, I have found the answer to the problem. To be honest, as most things are, it was quite simple in the end. The lpsolve55.dll wasn't recognized because I didn't have my new bin-folder in the Path, which I did have with my old project. I simply forgot.
On a further note however, after the lpsolve55.dll directory was added to the path, I still got an error telling me there was no model to be found that could solve my directive. Since the error occured when I was calling the LPSolverDirective(), some research landed me on the following page:
http://lpsolve.sourceforge.net/5.5/MSF.htm
Above page gives a complete and stable way of how to acces lpsolve55.dll using the LPSolverPlugin straight out of Microsoft.Solver.Foundation.dll. After following the method in the link that involves editing my projects' bin/Debug and bin/Release folders, I got the LP model up and running within no-time.
Morale of the story - read the documentation. I am a bit of a beginner in programming entire multi-project solutions and using customly-added dlls, but hopefully this helps someone else experiencing the same. In the end, I learned a lot by simply trying different methods of getting it to work, so no time was wasted.

SharpMap -Gdal Raster Layer, The type initializer for 'SharpMap.Layers.GdalRasterLayer' threw an exception [duplicate]

I started to use gdal_csharp dll in my application and read a geotiff file. but it says:
The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
it's my code
string fileName = #"/path to geotiff file";
OSGeo.GDAL.Dataset DS =
OSGeo.GDAL.Gdal.Open(fileName, OSGeo.GDAL.Access.GA_ReadOnly);
can anyone help?
Edit:
I have these dlls
This is the full error message:
It says that cannot load gdal_wrap. But when I'm going to add that dll to my application the below message is shown:

As an update to this there is now GDAL maintained by the SharpMap team as a nuget package here which is updated regularly. You'll need to install both the "GDAL.Native" and "GDAL" package for your project to use the GDAL library. Once installed via nuget, they'll automatically create a "GdalConfiguration.cs" that you call into to initialize the GDAL paths before starting. The only thing to note is the packages are setup to automatically copy their appropriate GDAL libraries to your output build directory. If you need to deploy the application you'll have to do a bit of extra effort.

To solve this one I downloaded the prebuilt libraries as described here and grabbed FWTools from here.
The unmanaged DLLs I used came from \install_dir\FWTools2.4.7\bin and the C# wrapper from \install_dir\FWTools2.4.7\csharp.
gdal14.dll, msvcp71.dll and msvcr71.dll came from here, which is mentioned in that first link.
The error you are receiving re gdal_wrap.dll is referring to one of its dependencies. I threw that DLL into depends and it found a lengthy list of dependent libraries. Note that this list is likely longer due to my use of the FWTools distribution - if you built your version from source it may look different, though the same principles apply.
To get the above code to work on my machine I had the following files in my output directory:
gdal14.dll
gdalconst_csharp.dll
gdalconst_wrap.dll
gdal_csharp.dll
gdal_fw.dll
gdal_wrap.dll
geos_fw.dll
geotiff_fw.dll
hdf5dll.dll
hdf_fw.dll
jpeg12_osgeo.dll
jpeg_osgeo.dll
libcurl.dll
libeay32.dll
libexpat.dll
libmysql.dll
libpq.dll
libtiff_fw.dll
lti_dsdk_dll.dll
mfhdf_fw.dll
msvcp71.dll
msvcr71.dll
NCScnet_fw.dll
NCSEcw_fw.dll
NCSUtil_fw.dll
netcdf.dll
ogdi_32b1.dll
proj.dll
sqlite3.dll
ssleay32.dll
szlibdll.dll
xerces-c_2_7.dll
zlib1.dll
zlib_osgeo.dll
Now these don't necessarily all have to live in the output directory - as long as they are on your path somewhere (e.g., \Windows\System32) you should be fine.

I know it's an old question, but I believe my answer might help someone.
I was able to successfully compile and run examples using c# gdal by doing the following:
Downloading GDAL sdk from http://www.gisinternals.com/ (64 bit in my case)
Executing the SDKShell.bat script to set the system environment paths, etc.
Creating a project in Visual Studio. And referencing all .net dlls (the ones that names end with _csharp.dll), located in \bin\gdal\csharp\ inside downloaded SDK
Setting platform target in Visual Studio project settings to x64 to get rid og bad image format exceptions. The last step wouldn't be necessary if I'd choosse 32bit version of SDK to work with.
I did not install fwtools at all. It seems like the last build of fw_tools is relatively old, and sdk is still maintained.

I know this is a reasonably old question now, but I found this in google after researching the same problem myself, so this means that for searches on this error this is still a very relevant page to update given it's still in the top 5 from the big G when the same problem is searched.
In my case it was the answers from "DeusExMachina25" and "Grzegorz Sławecki" that struck a chord.
I'm writing some software that makes use of the current builds of "sharp map" on NUGet (as of 24th of June 2016) and my software kept throwing the same gdal_wrap message as the OP originally reported, even though I'm using the GDAL package provided by the Sharpmap team.
I didn't realize that the NUGet installer for the package had installed a configuration class for me, but after reading through this thread and finding out that it does I went looking for it.
Sure enough I found the file 'GdalConfiguration.cs' in my project and added a call to it in an appropriate place in my project, expecting GDAL to be initialized correctly.
However, after I did this, I still had the same problem.
So, I set a break point on the beginning of the GDAL routine that had been added, and waited until the break point was hit.
I then traced through the method, and eventually found the following line:
var gdalPath = Path.Combine(executingDirectory, "gdal");
at around line 64 in the file.
Tracing through this, I noticed that the path being built was:
d:\geodata\maptest\maptest\bin\debug\gdal
but the NUGet installer had installed all the dependent assemblies in
d:\geodata\maptest\maptest\bin\debug
Exactly where I expected them to be.
I changed line 64 so that it now read:
var gdalPath = Path.Combine(executingDirectory, "");
and voila, the error went away and everything started to work.
I could have done things the other way too, and created a folder called gdal, then copied everything into that, but that then would have gotten deleted when I did a "clean" on the project.
Since the config class, set's up various environment variables based on this path, quickly changing that one line also fixes up the path for the GDAL data files , plugins and a few other things too.

You could try using Dependency Walker to see if there are any dlls that gdal_csharp is trying to grab but cannot.

Have you added the path to your GDAL libraries to your PATH environment variable? I downloaded my files from http://vbkto.dyndns.org/sdk/?_sm_au_=iVVqjsHS2n46WP00 and here's my path: C:\libs\release-1600-gdal-1-9-mapserver-6-2\bin.

To use the C#-bindings of GDAL you need an installation of FWTools (from http://fwtools.maptools.org/) as well as the most current binaries that match your system (from http://vbkto.dyndns.org/sdk/). Afterwards it is important to include the bin-directory of FWTools (example for 64bit-systems: C:\Program Files (x86)\FWTools2.4.7\bin) in your PATH variable as well as the necessary dlls (gdal_csharp.dll was mentioned in the question) in your Visual Studio project references. I outlined the complete processs here.
This process works on 32 bit as well as 64 bit systems, I tested it with VS 2010 and 2012.

Remove the path to python from the system variables. Because the main gdal paths conflict with python 27

Did you forget to:
GdalConfiguration.ConfigureGdal();
GdalConfiguration.ConfigureOgr();
Gdal.AllRegister();
Ogr.RegisterAll();

In my case the issue was:
I had 2 projects in my solution: ProjectA and ProjectB
I was executing ProjectA, and ProjectA was referencing ProjectB
ProjectB is the one that contained the references to both GDAL and GDAL.Native
ProjectA tried to find GDAL.Native's files under ProjectA\bin\Debug\netcoreapp3.1\gdal ... but in reality those files are under ProjectB\bin\Debug\netcoreapp3.1\gdal
Possible solutions:
Dirty solution: just copy the files from ProjectB under ProjectA\bin\Debug\netcoreapp3.1
Okayish solution: add the GDAL.Native package to each one of your "entry projects"
I don't like either of those solutions. This stuff happens under GdalConfiguration.cs, so maybe there is a way to modify it to find the correct path.

Unable to load DLL 'git2.dll' The specified module could not be found

I'm trying to use libgit2sharp in a web-project. The problem is that libgit2sharp's solution is for VS2010 and I'm using VS2008. So I had to create a new solution and modify the code not to use default parameters. That wasn't a problem, except I'm getting the exception listed in the title when I try to use the compiled libgit2sharp DLL.
I've tried linking in the git2.dll, but that hasn't helped. Copying the git2.dll into the web-project hasn't helped either.
Edit: The issue was handled over at the LibGit2Sharp issue tracker: https://github.com/libgit2/libgit2sharp/issues/39

Off the top of my head, I'd say that the git2.dll (compiled version of C libgit2 library) is not in your output directory (bin\[Release|Debug]).
As git2.dll is not a managed dependency, you cannot reference it from your project.
However, thanks to a prebuild event, you should be able to copy the binary to your output directory.
Another option would be to link to the dll file from within your solution and change its properties to make it 'copied if newer' (see below)
Should you encounter any problem, please create an issue in the bug tracker.
It will be easier to track ;-)
UPDATE:
In order for this to run, you have to make sure that after compilation, the file libgit2.dll is located in the same directory than the assembly LibGit2Sharp.dll. This way, the dynamic loading of the native library by the assembly will work as expected.
The git2.dll (compiled version of C libgit2 library) should be generated at the top level of your output directory (bin\[Release|Debug]).
More thorough information can be found in the ticket

Debugging "Could not load file or assembly" that only happens on some computers

So I recently updated my software and with the new version I supply a new dll-file, lets call it My.dll. Now, the old version works just fine on every computer I have tried.
The problems began with the new version. Specifically, so far on at least one computer, it states that "Could not load file or assembly My.dll". This even happens when I have dropped a copy of the software on a network drive and run the software directly from there. It works on every other computer but one, which still gives the exact same error where other computers work fine.
The dll in question is even in the same directory as the executable, so I'm really quite bummed here. I tried to google around a bit as well, but all the issues I found were related to ASP.NET specifically. Any ideas on how to go about finding the problem would be much appreciated.

It is possible that the computer in question has a DLL added to it's Global assembly cache. This would take priority over the DLL in the same folder.
More information about the GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=VS.100).aspx

Is there an old copy of the DLL lying around? Perhaps with a different name? I had a similar issue when I changed the name of a dll. Internally, the namespaces were the same.
In my case, an older version of the DLL was still there. .NET got confused with two assemblies in the bin directory having the exact same namespaces and classes, couldn't decide on which to load, and threw an exception.
Removing the older version of the dll solved the issue.

Use the Assembly binding log viewer and set it to log failures. This will give you some clues as to why it is not loading.

You could take a look at the error log using the Assembly Binding Log Viewer. First you have to turn on logging.

--Right Click on Project
--Goto Properties->Build tab
--Change Platform and Platform Target to Any CPU, Save and run