I am building a class library. This library will be deployed to the GAC.
In my library, I have references to some external dependencies. The dependencies cannot be deployed to the GAC.
When I deploy my library, and use it, it complains that it can't load the dependencies.
How do I deploy the third-party DLLs so my assembly can reference them?
To add an assembly to the GAC, you don't need to have all the references of that assembly into the GAC as well. So as long as the application that is using your assembly can find all the references it is no problem.
So either deploy all the assemblies privately (in the same folder as the application) or deploy them into that GAC and deploy only that exchange assembly privately.
UPDATE
The same rules apply if you're not the one building the application, but are just providing a library.
There is no way you can have another central folder which acts like the GAC but is not the GAC.
The users of your library should deploy at least that assembly privately with their application. That is no problem if you just provide the library and the users of your library do the deployment.
You can't provide an installer and have all applications use your library without at least requiring them to provide that assembly with the application. Usually that is not a problem for a .Net application. Not using the GAC makes installing basically 'xcopy deployment'.
Of course the other solution would be not depending on that assembly.
Related
We have an asp.net core application running on kestrel hosted in IIS on windows server 2008.
This application uses several base components and we are used to just install these components in the GAC and use assembly redirects to point all applications on the same server to the latest version of these components.
Everything runs fine when we deploy the application including all the necessary assemblies.
However, when we apply a redirect on a dotnet core assembly (we apply the redirect in the [app].exe.config, not the web.config) to a version that is installed in the GAC, we get a type exception ...
Application startup exception: System.TypeLoadException: Could not
load type 'my.company.namespace.coolest.component.helpers'
Curiously enough, the redirects for the plain old dotnet4 assemblies work when specified in the [app].exe.config, only the redirect for the dotnet core assembly fails.
So, I'm now wondering. How are dotnet core assemblies resolved? Which locations are searched for ?
(And ultimately, is it possible at all to redirect to a dotnet core assembly in the GAC)
[EDIT 23/OCT/2017:
Doh... turns out the latest dotnet core assembly from our team was bad..
so to answer my own question.. yes, assembly redirects (when specified in [app].exe.config) for dotnet core assemblies targeting full .net framework do work and ARE also searched from the GAC]
ASP.NET Core emphasizes a lot of Self-Contained Deployments, so if any assemblies (including ASP.NET Core runtime itself) of your web apps need to be updated, you should rebuild a deployment package and redeploy.
Framework-Dependent Deployments is just introduced to eliminate some disadvantages of SCD, but it still requires your own assemblies to be repackaged and redeployed if you make certain updates.
So forget about the GAC tricks and assembly redirection your team previously used (many other teams also use similar tricks), and follow Microsoft's new approaches. Maybe one day Microsoft would bring GAC to .NET Core, but that should look completely different from what it is today.
Reference: https://learn.microsoft.com/en-us/dotnet/core/deploying/
As Martin Ulrich indicated, it depends on the targetFramework..
For a .net core application targeting the full dotnet framework, assemblies are loaded just as we are used to.
(all assemblies, including the dotnet core ones)
In my case the assembly manager was loaded from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
For binding redirects, it checks application configuration file / host configuration files / machine configuration file
For retrieving assemblies, it looks in the GAC, then the current directory
Noteworthy, for a .net core application targeting the dotnet core 2.0, a "Runtime Package Store" was recently introduced.
Here the assemblies in the application directory are searched first, then the Runtime Package Store
(See also SO 35538093, Microsoft documentation and Runtime Package Store discussion on github)
I've successfully built a Precompiled Function (DLL) and but ran into some issues regarding Reference from my DLL to other .Net Framework libraries.
I first tried to promote only my DLL to Azure and that failed due to missing dependancies. Next I tried to use Reflector to list the actual dependancies of my DLL and include them with Nuget but ended up just copying every DLL from my project bin directory to Azure and it worked.
So what how do I tell what libraries are actually included by the Azure Function environment and which I need to Nuget or upload myself. I couldn't find any documentation on the subject.
With the pre-compiled model, you need to bring your dependencies with the assembly where your function is defined (much like deploying a console or standard Web Application).
The simplest approach is to deploy the files from your assembly's output folder. The Azure Functions Tools for Visual Studio 2017 will do exactly that for you, giving you the ability to publish directly from VS.
So in my application, I have an actor that uses Pinvoke to call some functions defined in a win32 dll. I also have a front end webservice that calls these actors.
When I run this locally, everything works perfectly. The win32 dll is found and loaded correctly and my actors can call functions from there.
However, when I deploy my solution to Azure, I just get an internal server error when the actor tries to load the dll. Theres no descriptive error so I think that the actor either can't find the dll or can't find one of its dependencies.
I already tried using dependency walker to figure out the dependencies. Most were typical windows binaries with the exception of vcruntime140.dll. I added this to the VS project as a resource file by right clicking on the Project and then navigating to Add>Existing Item and then editing the "Copy to Output Directory" property of the resource in the solution explorer to "Copy always". Is this the right way deploying a native dll to service fabric? I'm also running in release mode so there shouldn't be any debug dll's needed.
Some extra information - My project was initially ported over from a web api project and I was able to successfully call functions in the win32 dll when hosting my web api on Azure in release mode.
Let me know if I need to provide some extra information
So I figured it out. For people who may stumble upon this later, here is how:
When I used dependency walker, I saw that I had immediate dependencies on vcruntime140.dll and msvcp140.dll. However, by digging deeper, I noticed that msvcp140.dll has an additional dependency on concrt140.dll. When I copied this over to my server's bin folder, I didn't get an internal server error anymore and I was able to call into my win32 dll.
All of these are visual studio c++ redistributable binaries that are usually found here "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x64\Microsoft.VC140.CRT".
I'm using FxProtect .NET assembly obfuscator and I want to deploy the obfuscated .DLL that is in the package to Azure. How do I put back the DLL that I obfuscated back into the package? Do I unzip the .CSPKG that gets deployed to Azure and copy and paste the obfuscated DLL into the extracted .CSPKG folder and then zip it again to deploy?
If packaging from Visual Studio or MSBUILD, I'd like to suggest that you run a post-build event that obfuscates the generated .DLL's
I have a similar situation where I have a set of Azure packages that include references to assemblies which need to be obfuscated (they are part of a public SDK). I use Dotfuscator as the obfuscation tool, but the process will likely work for other vendors as well. Here is how I solved this issue:
In my case, the Azure package(s) contain a reference to a WebRole project. That WebRole project then contains project references to several other library projects that need to be obfuscated.
The build process takes three passes:
Build the solution, which contains all of the libraries and web projects. I have used the Visual Studio Configuration Manager to disable building of the Azure package projects, though that is not required.
Run the obfuscation tool to obfuscate the assemblies that require it.
Build and package just the Azure packages (via the Publish target) and instruct MSBuild not to also build any referenced projects.
That last part is key. If you don't tell MSBuild to not build referenced projects, it will rebuild them all, undoing the obfuscation. You do this by including the property BuildProjectReferences=false when building the packages.
To build the Azure packages from an MSBuild script, I use the following:
<!-- This should be run after Obfuscation to ensure the SDK assemblies included in the packages are obfuscated -->
<MSBuild Projects="..\Path\My.CloudService.ccproj" Targets="Publish" Properties="BuildProjectReferences=false;PublishDir=..\artifacts\MyCloudService" />
I am using WSPBuilder to build a wsp file for sharepoint. One of my referenced dll's is obfuscated with .Net Reactor. When building the wsp project, this dll is not recognized, the WSPbuilder is throwing an error. I am not with the solution of installing this dll manually as it should be part of a complete setup on a sharepoint farm with multiple web front ends.
Any solution or idea for a workaround?
The error i am getting is this:
Unable to resolve assembly 'WSPBuilder.XmlSerializers, Version=0.9.8.206, Culture=neutral, PublicKeyToken=2b778c59697d7d9e', please use DLLReferencePath to point to the directory where this DLL is located.
Thanks.
This problem is solved with WSPBuilder ver. 0.9.8.0406
See Unable to resolve assembly WSPBuilder.XmlSerializers