I created a console application and added Newtonsoft.json as reference for test.
After following the steps, I published the application (netcoreapp2.0) to ubuntu.16.04-x64 version and deployed it to a Ubuntu(16.04) machine, when I run the console application, it always shows below error even the package exists in /usr/local/share/dotnet/store
An assembly specified in the application dependencies manifest (RuntimePackageConsole.deps.json) was not found:
package: 'Newtonsoft.Json', version: '11.0.1'
path: 'lib/netstandard2.0/Newtonsoft.Json.dll'
This assembly was expected to be in the local runtime store as the application was published using the following target manifest files: artifact.xml
After I changed the path of Newtonsoft.Json.dll in dependency json file to absolute path, then it works.
Anybody had the same issue on Linux? Or how can I find out the reason, why can't application load the package by relative path in dependency json file?
It looks like you are targeting a manifest when you publish your code.
Starting with .NET Core 2.0, it's possible to package and deploy apps against a known set of packages that exist in the target environment. The benefits are faster deployments, lower disk space use, and improved startup performance in some cases.
This feature is implemented as a runtime package store, which is a directory on disk where packages are stored (typically at /usr/local/share/dotnet/store on macOS/Linux and C:/Program Files/dotnet/store on Windows). Under this directory, there are subdirectories for architectures and target frameworks. The file layout is similar to the way that NuGet assets are laid out on disk:
A target manifest file lists the packages in the runtime package store. Developers can target this manifest when publishing their app. The target manifest is typically provided by the owner of the targeted production environment.
https://learn.microsoft.com/en-us/dotnet/core/deploying/runtime-store
So you may want to take a look at your environment and ensure that your package stores do in fact have the required libraries, or that you publish without a manifest.
Related
I'm trying to use Magick.NET library to do image processing on Azure Functions.
I have tried the same code in a Console App (.NET Core 3.1) which works without any issues. However when running the same code in an Azure Functions Project, I get the following error.
Code:
var image = new MagickImage(File.ReadAllBytes(#"<My Image Path>"));
Exception:
System.TypeInitializationException: 'The type initializer for 'NativeMagickSettings' threw an exception.'
StackTrace:
at ImageMagick.MagickSettings.NativeMagickSettings..ctor()
at ImageMagick.MagickSettings..ctor()
at ImageMagick.MagickImage..ctor()
at ImageMagick.MagickImage..ctor(Byte[] data)
at FunctionApp2.Function1.Run(TimerInfo myTimer, ILogger log) <-- My Code
Inner Exception:
Unable to load DLL 'Magick.Native-Q8-x64.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
Inner Exception StackTrace
at ImageMagick.Environment.NativeMethods.X64.Environment_Initialize()
at ImageMagick.Environment.NativeEnvironment.Initialize()
at ImageMagick.Environment.Initialize()
at ImageMagick.MagickSettings.NativeMagickSettings..cctor()
I believe this is due to the way Azure Functions package is organized and the path Magick.NET is looking for its native binary to load. I can confirm that the native binary is written at \bin\Debug\netcoreapp3.1\runtimes\<platform>\native when the Function app is built.
I have traced the apps using ProcessMonitor for each app and can see Function app looks in the wrong location.
It looks in
\bin\Debug\netcoreapp3.1\ bin\ runtimes\[platform]\native
instead of
\bin\Debug\netcoreapp3.1\runtimes\[platform]\native
(Below traces are filtered to only show path contains Magick.Native and process name filtered to the Console app exe and func.exe)
Console App Trace
Function App Trace
I have also tried setting MagickAnyCPU.CacheDirectory to Directory.GetCurrentDirectory() but it hasn't helped.
UPDATE:
After building, if I copy \netcoreapp3.1\runtimes folder to \bin this fixes the problem, but I current don't want to rely on that trick if there's a proper workaround.
UPDATE 2:
This issue appears to happen only when using
<TargetFramework>netcoreapp3.1</TargetFramework>
and Microsoft.NET.Sdk.Functions version 3.0.x
It does not appear when using older versions. I have successfully used
<TargetFramework>netcoreapp2.1</TargetFramework>
and Microsoft.NET.Sdk.Functions version 1.0.x
without this issue.
So, is there a workaround to get ImageMagick to load native lib from the right place?
Potential Workaround is to get msbuild to copy the runtimes folder after the build completes.
Add following to csproj
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="xcopy /Y /E $(OutDir)runtimes\ $(OutDir)bin\runtimes\" />
</Target>
or right click project > properties > Build Events and paste the above command to post build event command line
This will copy all of the runtimes binaries, not just the one we want, increasing the size of final build.
UPDATE:
This may be a bug in Microsoft.NET.Sdk.Functions version 3.0.8.
These issues in the github repo are tracking this.
Version 3.0.8 places the runtimes folder incorrectly
Microsoft.Data.SqlClient is not supported on this platform with Microsoft.NET.Sdk.Functions 3.0.8
This seems to only happen when using Microsoft.NET.Sdk.Functions version 3.0.8 which seems to have only just appeared in nuget on Friday. I will instead downgrade to 3.0.7.
Alternatively if you don't want to downgrade,
You could use MagickNET.SetNativeLibraryDirectory as a work around
We are developing an Open-Source aPaaS product. The project is in its very early stage.
We use .NETCore, for Web Services, we want to use ServiceStack.
For now, we are using NuGet packages. But, the number of service operations have started to go up and exceed the limit of 10.
We tried to download the Servicestack .netcore source code from GitHub (both ServiceStack/tree/master and netcore branches) but it is failing to build. Following are the errors we get:
E:\user\Downloads\Ss\ServiceStack-master\src\ServiceStack.Client\error CS0006: Metadata file 'E:\user\Downloads\Ss\ServiceStack-master\src\ServiceStack.Interfaces\bin\PclDebug\ServiceStack.Interfaces.dll' could not be found
E:\user\Downloads\Ss\ServiceStack-master\src\ServiceStack\error CS0006: Metadata file 'E:\user\Downloads\Ss\ServiceStack-master\src\ServiceStack.Client\bin\Debug\netstandard1.6\ServiceStack.Client.dll' could not be found
Considering a plugin system with the following installation pattern:
/install_prefix/main.exe
/install_prefix/plugins/plugin.dll
If my plugin depends on a library compiled as shared, its dll should be installed in the exe path:
/install_prefix/main.exe
/install_prefix/plugin_dependency.dll
/install_prefix/plugins/plugin.dll
I found isolated applications can be used to keep the dependency side by side with the plugin as follows:
/install_prefix/main.exe
/install_prefix/plugins/plugin_dependency.dll
/install_prefix/plugins/plugin.dll
This relies on a manifest file generated with visual. I am using cmake to generate my projects and I can't find any reference on a "good" way to handle isolated applications in a cmake file.
Did anybody have this use case?
EDIT:
This question propose answers on how to embed an already existing manifest file. What I would like is a way to generate the manifest file in the build process, in a perfect world with something as simple as installing exports. Something like:
install(
TARGETS target_name
MANIFEST target_name.manifest
)
This would generate the manifest file and embed it with the target.
I am trying to build VTK from sources as it is a dependency to PLC library which I am trying to build.
I use ccmake.. to select all relevant groups to be built (including Group_imaging), and I can build VTK with no particular problems.
Though, I cannot find vtkImageLoader2.h (and many other headers) anywhere in the system. As these files are required by PCL, this is a problem.
I checked that the original file exists inside the source tree, and it is indeed inside IO/Image.
I can't understand why the file is not being build and deployed to /usr/local/include, I made sure all modules (groups) are ON in ccmake.
Is this file deprecated, or am I missing the way to deploy it?
EDIT: I discovered that the file belongs to module vtkIOImage that is part of the "StandAlone" group. The StandAlone group is set "ON" when i run ccmake. Is this a bug in the build scripts of VTK?
I am in the process of introducing NuGet into our software dev process, both for external binaries (eg Moq, NUnit) and for internal library projects containing shared functionality.
TeamCity is producing NuGet packages from our internal library projects, and publishing them to a local repository. My modified solution files use the local repository for accessing the NuGet packages.
Consider the following source code solutions:
Company.Interfaces.sln builds Company.Interfaces.1.2.3.7654.nupkg.
Company.Common.sln contains a reference to Company.Interfaces via its NuGet package, and builds Company.Common.1.1.1.7655.nupkg, with Company.Interfaces.1.2.3.7654 included as a dependency.
The Company.DataAccess.sln uses the Company.Common nupkg to add
Company.Interfaces and Company.Common as references. It builds
Company.DataAccess.1.0.8.7660.nupkg, including Company.Common.1.1.1.7655 as a dependent component.
Company.Product.A is a website solution that contains references to all three library projects (added by selecting the
Company.DataAccess NuGet package).
Questions:
If there is a source code change to Company.Interfaces, do I always need to renumber and rebuild the intermediate packages (Company.Common and Company.DataAccess) and update the packages in Company.Product.A?
Or does that depend on whether the source code change was
a bug fix, or
a new feature, or
a breaking change?
In reality, I have 8 levels of dependent library packages. Is there tooling support for updating an entire tree of packages, should that be necessary?
I know about Semantic Versioning.
We are using VS2012, C#4.0, TeamCity 7.1.5.
It is a good idea to update everything on each check-in, in order to test it early.
What you're describing can be easily managed using artifact dependencies (http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies) and "Finish Build" build triggers (or even solely "Nuget Dependency Trigger").
We wrote our own build configuration on the base project (would be Company.Interfaces.sln in this case) which builds and updates the whole tree in one go. It checks in updated packages.config files and .nuspec files along the way. I can't say how much of a time-saver this ended up being for us, even if it might sound like overkill at the beginning.
One thing to watch out for: the script we wrote checks in the files even if the chain fails somewhere in between, to give us the chance of fixing it on our local machine, check in the fix and restart the publishing.