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.
Related
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 Azure 2.7.
I created a C# cloud service that only contains a single worker role. After it's done, the solution contains
A ccproj
A csproj
Both are using the setting of AnyCPU.
I then added the PropertyGroup "Debug|x64" and "Release|x64" into both projects. Also changed the default to x64 for both. As a result, an x64 build.
However, whenever I select "publish" on the "ccproj", I notice that it always builds AnyCPU instead of x64. I cannot find how to force it to build x64 for packaging and deployment.
I then edited both proj file again, and removed the PropertyGroup for "Debug|AnyCPU" and "Release|AnyCPU". After I did this, and when I tried to build x64 again, I got error as:
C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(723,5):
error : The OutputPath property is not set for project
'AzureWorkerRoleExample.ccproj'. Please check to make sure that you
have specified a valid combination of Configuration and Platform for
this project. Configuration='Release' Platform='AnyCPU'. This error
may also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
I could not figure out how to work around this error.
Any idea on how to force VS to make a x64 build of cloud service and deploy it?
One workaround I found is that: keep AnyCPU property groups, but also put
<PlatformTarget>x64</PlatformTarget>
in the group. Thus the AnyCPU assembly are actually targetting to x64. But this sounds hacky.
Any idea?
Thanks a lot!
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.
Unfortunately, due to issues with Azure's lack of EF 5 spatial support, I need to include the relevant DLL myself: related link
Once I included the SqlServerSpatial.dll I was able to complete successfully deploy by using the Publish tool inside of Visual Studio.
However, when I try to use the Github -> Azure deployment with the relevant DLLs being available in the github repro, the deployment fails with the message:
The process cannot access the file 'C:\DWASFiles\Sites\<my app name>\VirtualDirectory0
\site\wwwroot\bin\SqlServerSpatial.dll' because it is being used by another process.
I'm not really sure how to troubleshoot from here and could use some help. Thanks!
use nuget package manager instead of adding the dll and pushing dlls using git.
PM> Install-Package Microsoft.SqlServer.Types
Ignore the bin folder from git by adding bin/ in .gitignore file
usually adding dlls in source control causing issues and its not a good behavior.
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" />