Load plugin by assemblyloadcontext ,but how to probe assemblyloadcontext and analyze the memory profiler of a single plugin in detail ?
In the .NET Core, it seems that only process can be probed, but cannot probe a single assembly, for example a plugin assembly.
Related
Setup:
single offline (blocked from inet) server
multiple applications
apps load .net core assemblies (plugins with their own assembly or nuget deps) at runtime through reflection
Problem: What is the most efficient way to deploy the application set?
Currently I publish application per application, so that all required nuget packages and assemblies are available. However, this means the complete .net core and asp.net assembly set is copied over multiple times.
To have a shared deployment with an installed .net core runtime or sdk, there does not seem to be an easy way to make the required nuget packages available on an offline machine?
Any suggestions on the best-practices setup for these kind of deployments?
Cheers.
Sounds like you could use the global packages folder.
If your projects use PackageReference they consume their dependencies directly out of that folder instead of copying them locally, so if you're worried about disk space that would be a way to avoid duplication if that's what you're really worried about.
I have an existing solution that has the server as .netcore v 2.1 and was calling an api to do all of the CRUD Operations, after a long discussion , i was required to remove these api calls with a direct call to a class library project that has repository classes that utilizes LinqToSql as ORM -Know it is too old , but they want to utilize the existing infrastructure- have done the refactor and build with no error, when in run time i was encountered with an error stating that could not load file or assembly system.data.linq version 4.0.0.0
I am not sure but is this because the .net core could not utilize a library (i mean the LinqToSql Orm library )that is not in .net standard v 1.0 or above or is it something else? i mean it is the other project that has it !
also another thing, i do not care for supporting linux so in case of any workaround that would be much appreciated.
For .NET applications, it is clearly documented how to do logging with Xray. The mentioned library is based on the .NET Framework and does not support .NET Core which became clear to me after installation (warning messages). There is an alternative that does not have a .NET Framework dependency. However, the xray documentation does not mention this library so hopefully someone can explain how to do logging with xray within a .NET Core application.
For a .NET core application add this line as soon as your app starts but after you configure log4net. If you're not using log4net then you can choose from a couple other logging options.
AWSXRayRecorder.RegisterLogger(Amazon.LoggingOptions.Log4Net);
You'll need to reference this assembly though. https://github.com/aws/aws-xray-sdk-dotnet
I have recently started learning ASP.NET Core with the help of an ebook. There are few statements mentioned in the initial chapters, which I am unable to understand clearly.
For eg. following statements are mentioned under Foundational improvements in ASP.NET Core section
Lightweight and modular HTTP request pipeline
Ships entirely as NuGet packages including the runtime
Runtime can be installed Side-by-side- allows you to version application along with runime
The above statements are not clear to me probably because of the term "modular HTTP request pipeline" from Point 1 and terms "runtime" and "version application" from Point 2.
Any short explanation or reference to the suitable doc will be appreciated.
Thanks
http request pipeline
They totally rebuild the HttpListener which is also called the http server. Normally you would host your application in iis which would give you tons of functions but is 1 very old, massive sluggish application.
Now on default you run the application as a console which starts up a HttpListener which is called Kestrel in dotnet core.
This kestrel is totally build from the ground up (so modular priciples and barely any technical depth). And is build based on a very vast C++ library called libuv.
The modularity in this means that it has been build in various loosly coupled parts, meaning that you could replace or extend those parts if you want to. For example use a test server for automatic integration tests.
Ships in nuget packages
Normally you would install a netFramework eg: 4.5.0 and you would already get all these system.* dlls eg: System.web.dll
Now all these dll's are nuget packages and bundled into 1 package called netstandard: https://www.nuget.org/packages/NETStandard.Library/.
Multiple runtimes
If you build a dotnet project, it creates Dlls. these dlls can be run by by any OS if that os has installed the dotnet runtime. (basicaly dll is intermediate language and can be run by the dotnet runtime).
You can also build your dotnet project to include the runtime inside your application, so you can run multiple dotnet applications on an OS with different Dotnet runtime versions.
The downside of this last option is that you have to build your dotnet project for every OS specifically. So normally people choose to just build the OS independent Dlls and make sure the right runtime is installed on the OS.
I am trying to send raw ascii data to a CUPS printer (raw queue) in a .NET application. My first thought was to use the classes PrintServer/PrintQueue/PrintQueueJob but running my application throws an FileNotFoundException for System.Printing.dll. If I understand the pages Mono Status and Mono System.Printing in 4.0 vs MS.NET 4.5 correct the System.Printing.dll and the classes are available in Mono. Am I wrong?
That page is almost now useless, as Mono project migrates to a GitHub Markdown based new site,
http://www.mono-project.com/docs/about-mono/compatibility/
System.Printing from .NET Framework uses too many Windows only APIs, so it does not make sense to bring it to Mono/Linux.
Another way to check compatibility is to directly check Mono source code,
https://github.com/mono/mono/tree/master/mcs/class
You can see there is no System.Printing folder.