I have an application that uses a handful of home brewed assemblies that builds and runs fine in VS2015 and when files are copied locally.
When I copy the folder structure from release to a server location, and run the exe from the Mapped drive path (H:/) it fails to find one of my DLL files. If I use the UNC path it loads fine. I have tried using fuslog (Assembly Binding Log) but it doesn't give me any useful information.
If there is any other information you need to help me troubleshoot, then ask away.
Thanks!
NOTES:
Using .NET 4.5.2
I did deploy as "Release"
Other Assemblies load fine and are noted as "operation successful" in fuslog.
Related
I have an application that is being installed from MSIX installer.
It is installing successfully, but when execute it after installation i get an error that there is no such a file in C:/UserName/AppData/Roaming/MyApplication.
What i have tried:
Creating the folder (from C# code) on the very beggining of the application.
Result: It was creating it somewhere, but i couldnt see it on a disk apparently. Even when i tried creating files in that directory, i could do it without exception. So im sure that this folder existed. Somewhere. When i ran application from MSIX it gave me previously mentioned exception.
I created folder from the OS manually to see if the error will persist.
Result: I ran application from MSIX and everything worked fine.
At the last step i tried to access priviliges to the C:/WindowsApp folder (thats where MSIX are installing things), and i tried to run application from there manually by executing .exe (not by MSIX like previous times), to see if the error will last.
Result: It created those folders without problems, and application worked fine.
Any ideas what im doing wrong, or what i could do avoid this error ?
PS. I cannot change location of path C:/UserName/AppData/Roaming/MyApplication, because it is being created by 3rd parties dll's (Devexpress).
Try searching for the files under this path:
C:\Users\User\AppData\Local\Packages(hash)....
That is where all MSIX packaged apps redirect their AppData resources.
However, if the files are found to be existing in the "real" AppData folder, the app will work with that copy, not the one from the virtualized location (this is international behavior from Microsoft, to smoothen the transition of apps from classic installers to MSIX).
That is why the application worked after you created the folder manually.
Also, note that the files from the virtualized location are accessible only to your application and can't be accessed by others from the machine.
I suspect that when run the EXE directly from the install folder (not from the start menu entry point) the OS does not launch app in the container of the MSIX package, so none of the rules of running as a packaged-app apply. Therefore you can ignore this scenario.
Go back to #1 and try searching for the files under the path I mentioned. How are you (Devexpress) accessing the AppData path? I assume they are using something in the lines of (this should be ok):
Environment.GetFolderPath(Environment.SpecialFolder.)
We have a project on .NET Framework that references the Fico Xpress solver dll. The dll’s required are –
Xprb.dll
Xprbdn.dll
Xprsdn.dll
As no nuget packages are available for using Fico Xpress Solver, we installed the Fico Xpress Solver and copied these dll’s from the installation directory to our local folder named lib inside the project folder and added path reference to these dll’s inside the lib folder. So when compiling, the project uses the reference of these dll’s (present in the lib folder) to compile. This project successfully builds. When our project calls the Fico Xpress Solver, then the above required dll's are used from the installation directory which is probably accessed through the environment variables (the dll's in local folder are just for successful compilation of code and we could have pointed it to the actual Fico Xpress Solver installation directory but we put the dll's in lib folder so that we can add it to the SVN) and the project runs successfully using the Fico Xpress Solver.
Now, we have ported the project to .NET Core so as to run the same on Linux machines. So we installed Fico Xpress Solver on the Linux machine and tested whether the installation was successful by using the optimizer executable inside the /opt/xpressmp/bin/ folder (this is the default installation directory for linux machines). Installation is successful and the Fico Xpress Solver runs correctly (checked it using the method given on their website).
When we build the project, it compiles successfully, as it still refers to the required dll’s inside the local lib folder. But, when our project calls the Fico Xpress Solver during run time, it fails as it could not load the required dll’s (which it was probably searching in the LD_LIBRARY_PATH which is set to /opt/xpressmp/lib/ as set by the /opt/xpressmp/bin/xpvars.sh script which was specified in the installation manual. This folder contains all the .so files and no dll files.) The error is as below –
Unable to load shared library 'xprb.dll' or one of its dependencies.
In order to help diagnose loading problems, consider setting the
LD_DEBUG environment variable: libxprb.dll: cannot open shared object
file: No such file or directory
We are not sure whether the approach we are using i.e. using dll's to compile and run is correct or whether we have to some how use the .so files to compile and run the project. As the code was building successfully, we expected it to run, but the shared object files are not found.
Can someone please specify a way to use Xpress solver in linux or some general guidelines that need to be followed when using the same 3rd party software on windows and then on linux. Do we need to change the code or add reference to .so rather than the .dll files
Is DllImport the only way to do this (suggested on different blogs)
We finally figured out a way to do so but we are not sure it will be applicable to everybody and it might not solve somebody else's problem. Here goes our approach -
As mentioned in the question, the xprb.dll could not be loaded because libxprb.dll was what it was searching for in the Xpress lib directory (/opt/xpress/lib/). But after installing the Xpress in Linux, the installation contained only .so files and no .dll files.
There were some blogs which suggested using DllImport method to load the .so files and then call the methods. We didn't try those methods as we were looking for something simpler than that.
After investing the problem we found that only if we point the loading of shared libraries to somehow the installed .so files, it might work. So the situation was as such in our specific case -
We did not have a libxprb.dll in the /opt/xpressmp/lib/ folder
We had libxprb.so file instead of libxprb.dll in the /opt/xpressmp/lib/ folder (if we didn't have this file we probably wouldn't have known which other .so file to use)
So we created a symlink file libxprb.dll in /opt/xpressmp/lib/ folder (which we probably could have placed anywhere as long as it was in one of the path in LD_LIBRARY_PATH) which pointed to the libxprb.so file in /opt/xpressmp/lib/ folder using the command -
ln -s /opt/xpressmp/lib/libxprb.dll /opt/xpressmp/lib/libsprb.so
So now when xprb.dll was loaded, it looked for libxprb.dll which in turn pointed to libxprb.so file (as libsprb.dll was a symlink to libxprb.so) and hence xprb.dll was loaded successfully.
I'm new to C# and .net in general, and I need to use it to work with the SDK for a major piece of software we use.
I can add the assemblies they tell me to add in a console application and everything works fine. When I try to add them to any web application (either MVC or WebAPI), I keep getting errors saying other assemblies are missing. Eventually I just added every assembly/reference (not sure the correct term for this, pretty much just .dll files) in the sdk folder and now it is working. This definitely cannot be the correct way to do this.
Is there something I am missing that allows assemblies/references to load other assemblies/references, or is something else the cause of my issue?
UPDATE:
The exceptions are usually something like this:
Could not load file or assembly 'Server, Version=1.5.1.0, Culture=neutral, PublicKeyToken=d11ef57bba4acf91' or one of its dependencies. The system cannot find the file specified.
And it does not occur during build, only when the function is actually being called from the web application( in my case, since it's an api, when I visit the URL that returns my JSON data)
You can use a tool called "IL Disassembler" that is installed along with Visual Studio to see what other dependencies the SDK's Assembly depends on.
The install location may vary but mine is here...
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\ildasm.exe"
Drag and drop the SDK's assembly that you are using onto the tool and click the manifest field. A dialog will open with the other assemblies that you'll need to include.
If your console application works but the web application does not then the exception should specify which assembly is missing.
Compare you console output directory with the output directory of you web build. Make sure the dll that is required is being deployed to the web directory you are running.
In visual studio with your web project find the assembly under references and select it. Make sure that the property "Copy Local" is set to TRUE.
I have developed a simple .EXE in Visual Studio 2015, which adds an item to the specified SharePoint site and List when the user runs some process.
The file is saved in a shared network drive, and everything seems to work perfectly except for one detail.
I can't seem to work out how to run the EXE without having the following .dll files saved in the same folder:
Microsoft.SharePoint.Client.Runtime.dll
Microsoft.SharePoint.Client.dll
If I move these from the folder in which the EXE is saved in, I get this error message when running the exe:
Unhandled Exception: System.IO.FileNotFoundException: Couldt not load file or assembly 'Microsoft.SharePoint.Client, Version=15.0.0.0, Culture=neutral ... Or one of its dependencies ...
I (think) I have set up 'strong named assembly' by following these instructions in VS for the app, and I was able to add the SharePoint dlls to the GAC by using the VS command line and gacutil.exe (with a successful confirmation message), but I am still unable to run the EXE without having the 2 .dll files present.
Note: I developed the app to target .NET-4, but the users will be accessing the files from a system with .NET-3.5 installed, however the server on which the EXE is saved on does have the .NET-4 environment.
I was able to achieve this by using a tool called ILMerge which can be found here and is available as a NuGet package.
ILMerge allows you to merge dlls and exe files into a single exe
My C# application runs fine (in both Debug and Release mode) when I run it through Visual Studio 2012 or executing the .exe through Debug/Release folder, but it fails when I copy that .exe to some other location and run it. The error message that I receive is:
Could not load file or assembly 'bms.Common, Version=5.0.0.1006, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I am copying the .exe from Debug/Release folder to some folder. Am I doing it wrong?
In Debug folder exists only .exe file? No other dlls? You should copy all .dll files from Debug folder to target directory along with .exe file.
If you want package all libraries into one executable assembly then look at ILMerge utility http://www.microsoft.com/en-us/download/details.aspx?id=17630
usage:
C:\Program Files (x86)\Microsoft\ILMerge>ilmerge C:\my.exe C:\my.dll /out:C:\merged.exe
Generally speaking, you should be deploying the DLLs in the same folder as the executable. With .NET we don't usually compile everything into one big .exe the same way you might link a c program.
There are certain exceptions: for example, you could put the DLLs in the GAC or put them somewhere else and provide what is known as a "probing path." Those are advanced approaches which should not be used unless you know what you're doing.
For complete information on how .NET resolves DLL references, I suggest you read here.