Is there any way to "Hot Publish" a .NET Core application? - asp.net-core

I am looking to move some .NET Core applications into production and with the old .NET framework you could update the compiled DLL's for the application's code at any point.
The next time the application pool recycled, you would get your new code - or you could recycle the app pool manually.
With .NET Core, it appears that the running application locks the DLL and it cannot be overwritten until either the process is closed through inactivity, or is ended via Task Manager (Window's server here).
Is the a preferred method to publish a new version without having to set a maintenance window for all the users? This is on a Windows 2012 R2 server running the .NET Core framework via IIS 8 and the App Pool having no managed code.

For ASP.NET Core hosted with Kestrel runs in separate process and IIS works like Reverse Proxy. So there is not way for DLL release unless you implement it you your application.
Set up a hosting environment for ASP.NET Core on Windows with IIS, and deploy to it section Deploy the application, item 4.
If you want to avoid downtime simply setup two websites on IIS with same set of settings, make an update on second website, put first down, and start second.

I think the simplest way is to copy all files into a fresh folder and changing the physical path of the web site.
For example, you have all web sites under C:\WebSites, you also have a subfolder for each web site such as C:\WebSites\MyWebSite and a subfolder for each version, such as C:\WebSites\MyWebSite\V01.00.
To deploy a new version V01.01, create a new subfolder C:\WebSites\MyWebSite\V01.01 copy all files to that folder and change the physical path of the web site.
You can easily change the physical path with PowerShell:
Import-Module WebAdministration
Set-ItemProperty -Path "IIS:\Sites\MyWebSite" -name "physicalPath" -value "C:\WebSites\MyWebSite\V01.01"
This is a form of "hot publishing". Additionally you can easily roll back to the previous version if something goes wrong.
Another alternative is to use symbolic links, for example C:\WebSites\MyWebSite may point to C:\WebSiteVersions\MyWebSite\V01.00. To deploy a new version, copy all files to C:\WebSiteVersions\MyWebSite\V01.01 then change the symbolic link so that C:\WebSites\MyWebSite points to C:\WebSiteVersions\MyWebSite\V01.01, and finally recycle the application pool. Click here to see code for doing that
There is also another option called "blue green deployment" strategy. This strategy requires configuring a single server web farm and two web sites. Please see this article for a complete description.

Related

Allow write permissions for ASP.NET Core API application

I am working on an ASP.Net Core 3.1 API application that downloads files. It will be saving those files to a folder outside the website. I know there will be an issue of allowing the process to write to the target directly. I found this post that talks about setting things up for .Net Framework on IIS7 (IIS7 Permissions Overview - ApplicationPoolIdentity) but I am deploying on IIS 8.5 and I am not able to find the user "IIS AppPool\DefaultAppPool".
Q1: So what exactly is the "IIS AppPool" part? Normally I am used to that being either the machine name or the domain name, but it is clearly neather since it is to be found on all machines.
SOLVED!!!!! I HAVE created a unique app pool for the app, let's call it 'upload-system'. I was going to ask how to enter it into the "Select User or Groups" and thought I should test it without quotes real quick... it worked!!!! I still want to know the answer to Q1, but I got the main problem working!!!!
The reason you cannot find the DefaultApppool is that your application pool may no longer have this application pool. If you want to give write permissions to the folder, you should try IIS AppPool\Application pool name. For example, your application pool name is Test. What you should assign to the folder is IIS AppPool\Test.
Find the application pool where your deployed application is located, and then assign this user permission to the folder.

Hosting blazor wasm asp.net core hosted app in kestrel

I am having troubles hosting the blazor wasm asp.net core hosted application.. The solution has 3 projects: Client, Shared, and Server.
when I run the command dotnet publish --configuration Release it publishes the libraries to their respective folders in solution like this:
WebWorkbench3\Client\bin\Release\net5.0\publish
WebWorkbench3\Server\bin\Release\net5.0\publish
...
I would assume that since the server project is referencing a client - then my steps to host the application are following:
Open WebWorkbench3\Server\bin\Release\net5.0\publish in powershell
Run command dotnet .\WebWorkbench3.Server.dll
Navigate to: https://localhost:5001/
Result:
Expected: client page opened
Actual: page is stuck at "Loading.." string. In the console we see that there was an error about _framework/blazor.webassembly.js not being loaded.
If we were to check the wwwroot folder contents in the server app we will see the following:
So this explains why the error is shown. However my question at this point - should the publishing process/configuration in project take care of copying client's wwwroot contents into the the server's app output directory? If we start a debugging session in the VisualStudio, then we use the server as the startup point, so the project should have some idea where to look up the blazor.webassembly.js file at..
So why doesn't the same process occurs during the publishing?
Note: I was able to fix the issue by manually copying the client's wwwroot directory and by placing the contents into the server's wwwroot directory... But I don't think that is is how serving is supposed to work?
EDIT: I have just tried to set-up the client blazor application in IIS. And it works. Kind of. The page is opened. But then when it tries to make a REST GET request to the server - it uses the same hostname:port combination. So if my app is hosted on mysite.local:50001 then the request to API will look like mysite.local:50001/data/loadall where data is the controller name and loadall is the action name.. So basically the client uses the same base address as the server.. The problem, is that I cannot start the server on the same port as the client! In attempt in doing so - you will see following output:
So basically I have the same question as before - how to host the wasm application that is split between client and the server? I am pretty sure that I can make it work by forcing the client to use the non-standard server port and serving the server part on that port.. However, I believe there should be a reason why current configuration (default configuration in the blazor wasm template) is configured in this way so it should be possible to run the project somehow without any additional changes at all..
Well this will be a self-answer.. Instead of publishing (dotnet publish --configuration Release) the application on solution level - do the publishing on project level..
before ..\repos\WebWorkbench3\WebWorkbench3
after ..\repos\WebWorkbench3\WebWorkbench3\Server
In 1 case the compiler does not copy the _framework folder (and possibly some other files) into the wwwroot.. Once you have published the Server correctly you can access the app by serving it with dotnet .\WebWorkbench3.Server.dll command.
Having the samie issue as explained above:
Before:
The solution file
had the same name
was in the same folder
as the server project
Resolved
I moved the solution to the project root (one level up).
Now, dotnet publish within the server project produced the __framework folder + content as expected.

Asp.net Core process is not shutting down after IIS restarts site

I have an IIS8 and I have deployed an asp.net core website (using the asp.net core module)
In order to update the site with new features every now and then, I clone the site in a different folder and change the web config so that the asp.net core module starts the application from that folder. Then I copy the new files in the web site root, and I change again the web config to point to the initial path in the root.
Changing the web config should trigger (and it does) an application restart. The old process should die (after a gracefull shutdown) and a new process (from the new path) should start.
The problem is that the old process doesn't die at all. A new one is spawned, but the old one is just there and I have to manually kill it from the Task Manager, otherwise I cannot overwrite the new files.
I thought, since the old process should die gracefully, there must be a long running request that keeps the old process alive. The only thing that came up to my mind is that the signalR client i use in the browser pages is keeping a connection to the server, and so it keeps the old process alive.
To test this theory, I opened the site in my browser and watched the Tasks in task manager. The application's process was there. I changed the web config file and opened another tab on the same address. A new process appeared in the Task manager. But the old one was still there even after several minutes had passed. I suspected the the first browser tab was keeping a connection to the old asp.net core process. So I closed the first tab. No more than a second after I closed it, the old process was terminated.
So is my theory correct? Does signalR client prevent the asp.net core process from shutting down gracefully after a web.config change? Shouldn't the server signalR component signal the clients to disconnect (or send a disconnected event) and then let the process die?
How do I overcome this problem? I want, upon a web.config change, the old process to terminate, not hang there forever and having to kill it manually.
It's hard to say exactly, as I've never even considered doing what you're doing, but my feeling is that this is down to changing the web.config. You're essentially orphaning the other Kestrel process. Yes, changing the web.config will trigger a restart, but it does so on the attached process. When IIS sees this changed web.config, it sees no process from that location running (since you changed the location), and thus just simply starts this new process.
If you're already deploying to a different folder, then simply edit the site in IIS and change the document root to that new directory. This will cause IIS to stop the site that's currently running (i.e. your existing process) and then start it up again, but now at the new document root location. Then you can delete the old folder if you like.

Default route in MVC working from VS, but not on test server

I have a very simple ASP.NET MVC 4.0 website. It's got a single controller ("HomeController") with a single action ("Index") which receives a single parameter ("string id"). I have not modified the global.asax file since this kind of route is handled by default. I have not created a view for this action since the action will simply be "sending" the user a file (a PDF). If I run the site from within Visual Studio (using a default page of "home/index/3" in project properties), the page runs fine. If, however, I publish the site to our test server (https://ourserver.com/mysite/home/index/3), I get a 404--File or Directory not found.
NOTE: We're running IIS7.5 on this server.
UPDATE: The bin dir (and the appropriate DLL, i.e., one named after the project) and the web.config file are there.
So, why is this not working?
If you're using an older version of IIS and haven't installed the MVC server extensions which give you routing, you can do a BIN deployment of the necessary infrastructure files.
Edit: If you're running IIS 7.5 you should have everything you need. You mention you don't see a web.config file or any dlls - how did you publish? You should absolutely have a web.config at the root of the publish directory and a bin folder with your dll(s).
If you right-click on your web project and do Publish, you can publish to a local directory. It'll be exactly what you should see when deployed.
Edit 2: Did you check that it's configured in IIS as a web application and not just a site?

Web Service Reference to reportservice20xx.asmx on a distributed application

I have an .Net webapplication which connects to a reporting web service.
In my development studio, I just add an webreference, then specify the path where the reporting server is installed and reportservice2010.asmx is found and ready for use.
But i do not know how to deal with it, after my application is compiled.
When I would like to distribute it on lets say 100 different servers.
The path to reportservice2010.asmx may(and surely will) change.
Of course what will make my application corrupt.
Please help !
When you added the web reference, Visual Studio should also have added a new section to the application's configuration file. That section specifies the environment-specific details of the web reference.
If, for any given target environment, the target address of the web reference changes then you can simply change the URL in the application's configuration file.