I have .net core project, When i build that project it generates .exe file but not .dll, My requirement is to create .dll of project and host it in IIS server. how to generate .dll file,what settings need to be done.
An ASP.Net Core binary is meant to be a self-hosted application, so the .exe embed a web server (the default one being Kestrel) that can accept HTTP requests. One of the challenges behind ASP.Net Core was to make it self-contained and decoupled from IIS. So having an .exe is perfectly expected, you can double click on it and you'll get a web server running.
That being said, in a standard production environment, you are supposed to have a webserver like IIS sitting in front of your ASP.Net Core app and acting as a reverse proxy, forwarding the requests to the app. So having an .exe file will not prevent you from hosting behind IIS.
I learned a lot from this article: https://weblog.west-wind.com/posts/2016/Jun/06/Publishing-and-Running-ASPNET-Core-Applications-with-IIS
If there is a way to create a DLL with ASP.Net Core, I don't know it, but what would be the point?
Switching the output type in your project properties to Class Library from Console Application will generate a DLL instead of an EXE.
Related
I have the server-side .NET Framework 4.0 project Server1.vbproj that references System.EntrepriseServices, and some classes that inherit ServicedComponent. I compile and register the dll with regsvc on servermachine1 and the COM+ application Server1 is created. I export the COM+ application as a proxy, install it on clientmachine1, and set the remote server to servermachine1. The proxy contains only the .tlb files.
I have the client-side .NET Framework 4.0 project Client1.vbproj that references Server1.vbproj which instantiates classes of Server1 with the New keyword (not with CreateObject). When running Client1.exe on clientmachine1, an exception is thrown, stating that Server1.dll is not found. If I register Server1.dll in the GAC of clientmachine1 it works.
The penetration assessment indicated, that it is not correct to have server-side dlls on the client.
I could nowhere find how to use System.EnterpriseServices client-side, is there somewhere some documentation?
Is it possible to get the client to work only with the proxy, without the server-side dlls?
Clients are Windows 10, servers are Windows Server 2012.
In IIS we had an aspnet_isapi extension that handles the request, it then spawns a process w3wp.exe, w3wp.exe then loads and starts the CLR and then CLR does its job.
Now, Kestrel is configured inside the Main() method, so first the Main() should execute, so who starts the Core CLR ? is it IIS for windows and Apache for Linux? Do IIS and Apache know how to search and start Core CLR?
What I know is, when a .NET application is executed at that time the control will go to the operating system, the OS creates a process to load CLR.
The program used by the operating system for loading CLR is called runtime host, which are different depending upon the type of application that is desktop or web-based application i.e.
The runtime host for desktop applications is an API function called CorbinToRuntime.
The runtime host for web-based applications is the ASP.NET worker process (aspnet-wp.exe).
So, how is it possible that first the Main() method will execute and then the CLR, i am not able to digest it, please help.
Forget about everything you know about IIS.
For Apache or nginx, just run your ASP.NET Core console application (who initializes Core CLR) at a local port (http://localhost:5000 for example), and then set up reverse proxy rules to forward external traffic to that port.
That's roughly what Microsoft documented in this article
Such reverse proxy setup is common, as other web stacks (Node.js, Python, Go) are using the same approach.
Because of this specific setup, Linux launches your .NET Core console app by analyzing the COFF envelope (of dotnet executable, or your own executable for self contained deployment) to locate the native entry (not your managed Main).
Apache/nginx is not involved in anyway.
Calling into this entry triggers CoreCLR initialization, and in turn your managed assemblies are loaded and managed Main is called.
You might find articles like this helpful.
I inherited a large web site. To the user, it consists of 20 "modules" with different functionality. Each module can be accessed via a menu from each other module.
Each module has been implemented as a separate Web Application in IIS, all sitting under the Default Web Site. They all use the same App Pool. All implemented in ASP.NET Core (net5).
The modules share about 70% of their code. This library code sits in several projects. The web application projects all have References to the library DLLs. After everything has been built, the bin folder of each web application project has a copy of the library DLLs (so there are then 20 copies of each library DLL on disk).
Assuming that web application 1 is receiving requests and has been loaded into server memory. If web application 2 then gets loaded into server memory, will the library DLLs then be loaded into memory again for web application 2? Or will web application 2 use the library DLLs that have already been loaded into memory for web application 1? As in, after web applications 1 and 2 have been loaded in memory, will there be 1 copy of the library cod in memory or 2 copies?
Reason behind the question is that I need to reduce memory usage on the web server. There are no operational benefits to having separate web applications. They are all deployed together in one go. We never start or stop just one of them, it is always all or nothing. Wondering if I can save memory by having 1 big web application instead of 20 smaller web applications.
Your ASP.NET Core web apps in the same application pool are configured to use out-of-process hosting, so all their assemblies/libraries are loaded into individual .NET Core processes (Kestrel based) (dotnet.exe usually, or your own executable when self contained deployment is used).
Diagrams in that Microsoft article make it super easy to understand the relationship among the runtime processes.
In that mode, IIS worker process(es) w3wp.exe only loads the ASP.NET Core module to work as reverse proxy.
Combining the two above, the answer to your question Do IIS Web Applications that use the same App Pool share DLLs in memory? is rather clear that nothing is shared and you cannot share anything either due to the process boundary.
Been doing this for hours now and it drives me nuts.
On windows 7 I installed IIS 7.5 through add windows features, also installed WCF HTTP activation, also did all the command line registrations.
In VS 2013 I have a WCF Services project that runes very fine when I run it in IIS express but I want to test it together with my front-end.
But when I browse to my .svc file in the browser it just keeps getting downloaded, been searching google but get wrong results all the time, hopefully! Someone can help me.
Greets
If your WCF Service is in .Net Framework 4.0/4.5, then check the .Net Framework version in Application Pool.
If it is 2.xxxxxx, change it to 4.xxxxx.
We are creating a WCF service with a companion client DLL (.Net) that we will be delivering to a user's GAC via a web page. The DLL knows how to communicate with and how to interface with the service, and will allow the web page to communicate with the WCF service via client-side Javascript calls. The user's machine will be executing the DLL's functionality, not the server. With it data will be transferred to the target server.
This works in theory (and practice) over our internal network. The network is, of course, in a trusted zone so there are no problems with delivery, GAC install and DLL utility. The client-server pair works as expected. We can download the .Net DLL with an object tag, install it in the GAC and use it easilly.
In order for an internet user to be able to download the client .Net DLL however there are security procedures that need to be put in place. We do not have the expertise yet to know exactly what they are, but we are aware that we will need to at least sign the DLL with a trusted certificate. Beyond that, we are unsure.
The question then is what do we do from here?
Give the assembly a strong name (sn.exe - etc)
Create a Windows Installer Project from Visual Studio that will add your custom assembly to the target machine's GAC. (Right click File System on Target Machine | Add Special Folder | Global Assembly Cache folder). Let users download your installer from your web page, probably the most painless way instead of forcing something via the browser.