I have C# application (.NET Framework 4.6.2) with WebApi projects which references System.Runtime.InteropServices.RuntimeInformation (v4.3.0) library through nuget package. See
Nuget package reference screen Package was auto-installed as a dependency of 'Microsoft.CodeAnalysis.Razor.2.2.0, Microsoft.DotNet.PlatformAbstractions.2.1.0'
This application was working fine (Builds from my localhost are ok) until I tried to do automatic builds from my teamcity server (different machine). For some reason builds of my app which are provided by teamcity will not start. I get error Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0...'
So I started to investigate and I found out this:
Builds from my localhost (bin/debug) contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.26011.1, Date modified=10.8.2021) --this build works fine
Teamcity build contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016) --this build is not working
Nuget package which was downloaded (..\packages\System.Runtime.InteropServices.RuntimeInformation.4.3.0) on both machines (localhost and teamcity server) contains System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016)
And now I am stuck and literally dont know how to investigate it further. Questions I am asking myself:
How is it possible that my localhost builds contains this reference lib with file version 4.6.26011.1 when in my \packages\ folder this .dll contains file version 4.6.24705.1? Does msbuild maybe take this reference from different location? But from where? I swear I searched my computer and I did not found this library in version 4.6.26011.1 (which is apparently copied to bin/debug by msbuild).
Is there a way to monitor msbuild process and see from where it copies this .dll reference to my bin/debug/ folder on my localhost machine?
How to fix my references so the app runs fine?
21.6.2022 Edit:
Thanks to #mu88 comment I have managed to find out that this library is copied from this location: "C:\Program Files\JetBrains\JetBrains Rider 2021.2.2\tools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net462\lib\System.Runtime.InteropServices.RuntimeInformation.dll" to my bin\debug. I have zero ideas why msbuild is using this path for this lib. (This is only library which is copied from this path)
--Additional info: I am using some AspNetCore references (e.g Kestrel, ..) so I am targeting .Net Standard 2.0. Could this relate? I am asking because my investigation lead to this issue: ms-build-extensions-file-corrupt-my-bin-web-api-folder. In this issue I have found other links to people having similiar problems like this. I just dont understand the solution there :(
So I managed to solve my problem. I had to install .NET SDK to Visual Studio Build Tools 2019 via Visual Studio Installer. Which done "some" magic and it created *MSBuild\Microsoft\Microsoft.NET.Build.Extensions* folder to my msbuild and now during the build process some System libraries are "overidden" and copied from this new location.
So even if I use nuget to download System lib then this package is not used during the build.
I did not manage to find any more info about the build process :( It would be nice if someone could explain this to me. I created a separate question for this here: What is Microsoft.NET.Build.Extensions and how does it work?.
Related
I have a .net framework project with framework as 4.8. Recently I integrated docuSign 5.12 using a class library and nuget packages. Everything worked fine in development. When I published the exe in server, I am getting could not load file or assembly error. I cleared the references, reinstalled docusign, changed copy to output property to true for all and published again. But same result.
What I noticed is, when installing .net framework in server, it didn’t create a folder called .Netframework in ‘c:\Program Files(x86)\Reference Assemblies\Microsoft’. As the required dependencies missing are system dependencies, they are not copied to published folder.
So, I have another server where .net 4.8 SDK is present and everything worked fine there. My questions are
Why didn’t installation in server didn’t create assemblies?
Do we need to install .net 4.8 SDK for this to work?
How to publish dependencies for these kind of Nuget packages?
I have not added code samples as it is working already. Dependencies are https://www.nuget.org/packages/DocuSign.eSign.dll/5.12.0#dependencies-body-tab.
You can use the publish functionality of VS. It will package your app, including all NuGet dlls and their dependencies and send it to server. If you use Azure - it's integrated into the process. You can even include it in a CI/CD process. But your specific problem can be addressed by just having VS publish the app to your server instead of you manually copying files over there.
As per the comment from Ralf, I checked the references. Found an interesting thing. I already had a binding redirect in the project but, it was added to the class library config file but not the startup project config file. Because of that, my API was referring to old Newtonsoft version. I copied redirect from class library config to my main project config and it started working.
I am working on a .Net application and planning to use SQLite as its back end.
I ended up with “Not able to load SQLite.Interop.DLL”
Then I found the documentation in http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
But I’m not able to find a zip that contains all the essential files mentioned in the above documentation. All the files are either separated or in NuGet packages.
Can someone help me out to find a zip the contains the following DLL files as a zip in a single zip ?
<bin>\System.Data.SQLite.dll
<bin>\System.Data.SQLite.Linq.dll
<bin>\System.Data.SQLite.EF6.dll
<bin>\x86\SQLite.Interop.dll
<bin>\x64\SQLite.Interop.dll
I don’t want to reference a NuGet package with my project, as I’m building this application using ANT and signing this is a separate build server that I’ve setup to compile and check the MSI files and it’s generation.
I’ll add a copytask to my ant build and copy all the dll files to the project before building it into msi. The only thing missing is a zip that contains all these above essential files.
PS : I need this application to work on both x86 x64 arch.
I've Searched around almost many sites and like #Blindy and #Selvin said there is no way around NuGet packages it seems.
Hence, I've downloaded the NuGet package from http://system.data.sqlite.org/downloads/1.0.113.0/System.Data.SQLite.Core.1.0.113.0.nupkg here which seems to contain SQLite as well as Platform Interop files.
Once I've downloaded these,
In VS, Tools -> Options -> NuGet Package Manager -> Package Source -> Added a new source as my local folder.
I've placed the downloaded package inside this folder
Project -> Right Click -> Manage NuGet packages -> Under the browser tab, I've selected the RHS filter as the source I've added in the previous step and the package I've downloaded was listed under here.
I Installed them and this created a packages folder inside my solution directory.
Then I was able to use System.Data.SQLite in my application. But it still threw "Could not load SQLite.Interop.dll". To tell the builder that you have to use the interop files, open the csproj file for the project and add,
<ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles>
And then this started working properly. I might use this as a structure instead of running a copytask in ant I guess.
Thanks to #Selvin and #Blindy
I am migrating a medium-sized Win10 app (.NET Framework 4.8) to net5-windows. The solution contains about 30 projects.
While the migration process worked rather straightforward in Visual Studio 2019 (Version 16.8.3) the only problem remained to package everything in a self-contained exe. Instead of struggling with the project entries in VS, I am using the command-line method discussed by Scott Hanselmann in his blog. This also worked smooth and produced an exe of about 140MB size.
One issue remains: Not all of the system dll's are included in the exe. The following ones have to be copied manually to the directory of choice:
Without these DLLs the app does not work.
My question: What is the reason for this behavior, and how can these dll's be included in the self-contained exe?
To include a system DLLs into single file app you should use IncludeNativeLibrariesForSelfExtract property or /p:IncludeNativeLibrariesForSelfExtract=true switch for dotnet publish command, as mentioned in single file publish design document
I am working on a vsix project where I need to get information about a local git directory. I am following this article. When I am using LibGit2Sharp library, I am getting an exception as described in following image and error:-
How can I resolve this?
VS version details:
Visual Studio 2019
.Net Framework 4.7.2
LibGit2Sharp is a managed language (.NET) wrapper around a native (C) library, libgit2. It's a P/Invoke layer, plus a layer to give .NET semantics (objects, etc). This means, though, that you require both the LibGit2Sharp.dll (the managed-language side) and the git2-xxxxxxx.dll (the corresponding native library) that it calls into.
The native DLL is part of the LibGit2Sharp.NativeBinaries project that LibGit2Sharp takes a dependency on. It should be installed (transitively) when you install LibGit2Sharp itself. And although it tries to set itself up as a dependency that will be installed in the output directory, since native binaries are not well-understood in the .NET project world, this can sometimes fail, especially for more complex project types like VSIX.
Ultimately, LibGit2Sharp will look for the corresponding native DLL alongside where it's located. So within your output directory, wherever your VSIX is being executed from, try copying the git2-xxxxxxx.dll that is part of the LibGit2Sharp.NativeBinaries project to that location.
Once you've identified the correct location for the git2-xxxxxxx.dll binary to live, you should copy this as part of your installation for the project. (eg Build action: None, Copy to output directory: Copy always)
I had the same issue and I solved it like this:
Copy the dir folder from VisualStudioExtension -> Bin -> Debug -> lib to the root of the VisualStudioExtension project. This folder contains the DLL files required for LibGit2Sharp to work.
Drag the lib folder onto the VisualStudioExtension project in Visual Studio.
Select the dll files, right-click, Properties, and set it to Copy always and include in VSIX.
That worked for me.
LibGit2Sharp has a dependency on the git2-106a5f2.dll which is under [Debug|Release]\lib\win32\[x86|[x64] directory.
If that particular version is missing, you may need to reinstall LibGit2Sharp library, but uninstall LibGit2Sharp.NativeBinaries library between uninstall and install.
The following operations on NuGet packages should help:
Uninstall LibGit2Sharp.
Uninstall LibGit2Sharp.NativeBinaries.
Install LibGit2Sharp.
Note: do not update LibGit2Sharp.NativeBinaries even if there is a newer version.
I got the same issue. It turn out I ignored the dependecies.
Installing its dependency : LibGit2Sharp.NativeBinaries sort out my problem.
For me, I manually installed the Debug and Release VSIX, and tested against regular VS instance and it worked fine. The LibGit2Sharp threw a DllNotFoundException only when debugging my code via the Exp version of Visual Studio 2019.
So I deleted the entire Extensions folder of the Exp verison of Visual Studio. It is the folder where the Exp version of VS installs all Plugins, like other versions of VS:
%AppData%\Local\Microsoft\VisualStudio\16.0_a31c0a3aExp\Extensions
The next time I debugged my VSIX through Visual Studio, it worked. Hope this helps, I think it has something to do with extensions.en-US files inside that folder. Deleting just my plugin folder insted the Extensions folder did nothing.
I have encountered this error when I am adding the DAI.dll to the assets folder.
this error happens when I try to build.
UnityException: Failed to run reference rewriter with command --target="Temp\StagingArea\DAI.dll" --additionalreferences="Temp\StagingArea","C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17134.0\Facade","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.AI.MachineLearning.Preview.MachineLearningPreviewContract\1.0.0.0","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.ApplicationModel.Calls.CallsVoipContract\3.0.0.0","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.ApplicationModel.SocialInfo.SocialInfoContract\2.0.0.0","C:\Program Files (x86)\Windows Kits\10\References.....(followed by alot more of this)....
I am using visual Studio 2017 version 15.7.3 and Unity version 2017.2.0b7
I have added the DLL to the assets folder in unity.
These are my player and build settings.
You need to change the settings in unity (Settings example in the photo below):
Find your dll file in your project inside Unity.
Click on it once to highlight it.
You will see the dll options in the Isnpector
Usually for HoloLens, you only select "WSAPlayer"
Click Apply to save settings.
Rebuild
Warnings
Sometime the dll that you trying to include is referencing something else is not included and that's why it will not work, but the error will be different than what you got.
Sometimes you may need to import an older version of the DLL. For example, I tried to import Newtonsoft.Json 11.0.2, but 11.0.2 was referencing a newer core framework than the solution that unity generate. There is a way to update it, but I didn't want to deal with it every time, so I found out that the highest version that I can use is 9.0.1 (I had to skip 11.0.2, 11.0.1, 10.0.3, 10.0.2, 10.0.1).
Also, keep in mind that you should include netstandard dll.
I usually have UWP test project in hand to try to test my dll with it. If it works there, then it is a good first step that it may work after importing it to Unity assuming it does not have dependencies.
Last result workaround
You can comment the code that references your dll
build the project from unity without the dll
in the generated UWP solution, you can add dll normally and even use nuget to install your desired dll
Uucomment your code.
Build your solution then deploy to your device or create a package to deploy it to device or store.
This works nicely as a work around.
One issue with this is that you will need to import dll or install nuget every time solution generated if it was deleted. It gets annoying and if you are working with a team, it can get confusing when they get the project and think that it does not work. Meaning you need to do more work to communicate and deploy.
Second issue, Unity is moving away from .NET backend to IL2CPP (I don't think you can do this in the CPP generated project). Meaning this is a short term workaround.
Consider upgrading to Unity 2018.2
Using .NET 4.X instead of .NET 3.4 Equivalent made my life easier with references and issues related to references and using more modern C# code.
You can install it and still keep the 2017 version if you install Unity Hub. This will minimize the risk of considering the update.