We Keep Coding

Looking for info on ninerays.win.widgets.dll

I've inherited a C# program that makes extensive use of widgets from ninerays.win.widgets.dll. The solution builds fine and even runs under mono in a Armbian Linux environment.
However I have to make modifications to this program and I have no documentation regarding this DLL. I wonder if anything is out there. Also when I attempt to open some of the panels in Designer I'm seeing this error:
I wonder if part of the problem is the NineRays dll file.
I would appreciate any documentation on this dll file and any suggestion on opening panels in designer.

this is not sponsored!
get dotpeek and let it create some documentation for you :)
https://www.jetbrains.com/decompiler/

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.

Problems using Excel Interop in SSIS

I am using Excel Interop in a SSIS Script task on a server with Excel 2007 installed.
Since a few days, errors appear when I try to open the script task. Whenever I open the code, the references to Interop are marked with a yellow warning sign and the namespace cannot be referenced.
I cannot add it again via "Add References", and when I try to add Excel Object Library in the COM Tab, it is also added with yellow warning signs (I couldn't find an error message for that).
However, when I don't save the changes and just run the whole project, it works without problems. Interop therefore seems to work, but it is somehow not found in Visual Studio.
I tried to install the PrimaryInteropAssemblies again, without success. The interop assembly is still found under c:\windows\assembly. The strange thing there is, that there is no processor architecture given for the assembly, while it is on my development machine.
I tried to uninstall the assembly to then install it again, but couldn't do it due to insufficient rights (even as administrator).
I had to install the Windows SDK a few days ago to use gacutil, could that be the reason for the missing reference?
The programming language is C# 2010 with Visual Studio 2010.
Thanks,
EDIT: I found a solution, although it still doesn't work as it is supposed to be. Here is how it works:
The problem can be solved by setting the "specified version" property of the reference to false. New projects can use the interop by referencing to it under C:\Windows\assembly\GAC\Microsoft.Office.Interop.Excel\12.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll

with a bit more of experimenting, I finally found a solution to the problem and want to share it here. It definitely isn't as it is supposed to be, and I would still really appreciate if somebody knew the reason behind that problem.
The problem can be solved by setting the "specified version" property of the reference to false. New projects can use the interop by referencing to it under C:\Windows\assembly\GAC\Microsoft.Office.Interop.Excel\12.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll

Exception while using GDAL in C#

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.

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