So I know this exists as I had found it recently after core was announced, and I have actually done it in the past. I just cannot remember a specific file name.
When Asp.Net Core 1.0 or 1.1 was out, there was a feature in the IIS module that would watch the root directory for a special .html file with a certain name.
If that file appeared, it would shutdown the Core app, and serve that HTML file. This enabled you to cleanly upgrade without having to find and kill processes. When the upgrade was done, you remove the file and the process starts.
I cant remember the required filename
I'm also not sure that this feature has been included in newer versions of the aspNetCore IIS module.
Anybody remember this?
It is well documented as app_offline.htm,
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-2.1#app_offlinehtm
Related
I launched an appimage using appimagelauncher. Then, I modified some settings of that app.
I know that appimages are not installed, so it can't be uninstalled. So, I deleted the appimage file.
But, when I downlaoded the appimage again, I observed that the user's previously modified settings were still there.
Now, how can I completely remove those user modified settings and launch that software as if it were newly installed?
The AppImage format doesn't define an explicit place where the applications configuration should be installed. Which means that the application can write such file wherever they please (as a regular installed application does).
Applications usually write their configurations to "$HOME/.config", you can look there for a file or folder with the application name. You can also ask the application author or check the documentation.
When using selfhost .Net Core 2.x, all the build artifacts are statically served by default, since the default directory is the same place as the binary/exe.
This means if one knows the names of the dlls, they can just request
them at /Whatever.dll, or they can also get any config files by name,
i.e. appSettings.
If you change things so that that the root directory is different or that directory is not in the VFS, /metadata stops working.
Is it possible to have /metadata work, but not allow the service's dlls etc to be statically served?
I have tried restricting the paths. This will keep settings / dlls / exes from serving, but the /metadata page will come up completely blank.
The /metadata page isn't related to the static file directory location, you may have caused a Startup Exception that's impacted how it works. If you can put together a stand-alone project on GitHub which shows the issue I can investigate.
Only extensions in Config.AllowFileExtensions can be served, you can remove .dll from being served with:
Config.AllowFileExtensions.Remove("dll");
.exe aren't servable by default, if you can download them you might be downloading them with .NET Core's static file handler instead.
It's common practice to have the WebRoot outside of the project root which for .NET Core is typically /wwwroot.
edit: Updated suggestion to remove the badness.
What I ended up doing at first was to add a .UseWebRoot() onto the
builder, then later switched from the selfhost ServiceStack template
to the web template per Mythz's suggestion. The web template was
set up in a way that solved my problem.
Thanks again.
for example, there is an application written using dot net core 2.1
Published under the IIS (Windows Server 2016). At the root of the application (near to the binaries (.dll)) random files are being created and modified. Will this affect the performance of the application? Will it make a difference if these files are created in a subdirectory next to the binaries?
If we exclude IIS and host under Kestrel, will it affect somehow?
As far as I remember, when hosting applications, written on a .NET fullframework, under IIS, and modifying any file (for example, a text file) in the BIN directory resulted in restarting the web application.
I do not know what files are being created and modified i would separate them form the app files for security reasons to say the least. Having said that to answer your question.
It should not affect the performance unless the volume of operations is so large that it will use up all iops on the drive or the pc/ram of the machine.
Kestrel will not be affected unless you try to modify files that kestrel uses for the app in some way and if you use dotnet watch run it will try to recompile them and run in the host if not it will ignore their existence until the host is restarted.
IIS should ignore them as well but i do not know what will happen if you have those files in bin and try to restart the host. i have tried changing and adding a file and did not restart. Maybe there is something in IIS settings but since i have not setup our IIS my answer is lacking in that regard.
Is there a way to copy only modified files to Service Fabric.
I have a Service Fabric application containing an ASP. Net 5 application as service. Whenever am doing a change to a JavaScript file inside my ASP. Net 5 service, every time I need to copy the entire service fabric application package. Is there a command which allows to copy only the modified file?
The best way to accomplish this is to use diff packaging and app upgrade. See this link for more info: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-application-upgrade-advanced/. Diff packaging allows you to define an application package that only contains the package parts that you wish to upgrade. However, it only applies to a component of an application package, such as a Service or Code package for example. You can't create a diff package at the file level. So if you've only changed a single file in your code package, you must include that file along with every other file that belongs to the code package. You can't just include the single file that changed. But the benefit of diff packaging is that you'd only need to include that single code package. You wouldn't need to provide other Service's code packages, for example, assuming they haven't been changed.
Service Fabric SDK 2.5 brings in a preview feature called "Refresh Application".
Using this feature you can get quicker feedback of your code changes.
To enable that, set the following from project properties
Application Debug mode = Refresh Application.
More details and limitations can be found here:
https://sharepointforum.org/threads/speed-up-service-fabric-development-with-the-new-refresh-application-debug-mode.111162/
In Fabric Explorer you need to find the node where you Web Application is running. I my case that is _Node_0
By SF SDK design, local SF published file is under C:\SfDevCluster\Data_App\ . In my environment, the website file path is C:\SfDevCluster\Data_App_Node_0\Application1Type_App1\Web1Pkg.Code.1.0.0\wwwroot\
So you can also find your HTML, CSS, JS and other static resources under below path: C:\SfDevCluster\Data_App[node_id][application_type_and_instance_name][service_type_and_version]\
You can just modify the files in this folder, then the change will immediately apply to your local test web browser. Please notice if your service is hosted by micro-service running in several nodes, you may need to modify all nodes files because load balancer may access any folder files randomly.
I am aware that any change to ANY file in the BIN directory will trigger an application restart in IIS. Are there any other "special" cases where changing a file or moving a file in any other directory will trigger an app restart?
I know this is a very old post, but may be helps someone:
See this: http://programming360.blogspot.com/2009/04/what-causes-application-restart.html
ASP.net run-time environment implements a good deal of checks and automatically restarts an application if any of the following scenarios occur:
The maximum limit of dynamic page compilations is reached.
The physical path of the Web application has changed, or any
directory under the Web application folder is renamed.
Changes occurred in global.asax, machine.config or web.config in the
application root, or in the Bin directory or any of its
subdirectories.
Changes occurred in the code-access security policy file, if one
exists. Too many files are changed in one of the content directories.
(Typically, this happens if files are generated on the fly when
requested.)
Changes occurred to settings that control the restart/shutdown of the
ASP.NET worker process. These settings are read from machine.config
if you don't use Windows 2003 Server with the IIS 6.0 process model.
If you're talking full advantage of IIS 6.0, an application is
restarted if you modify properties in the Application Pools node of
the IIS manager.
If you change the web.config you app domain should also be reloaded and assemblies flushed.