I was playing around on my local machine with getting RavenDb to use SSL running in server mode. It worked, after a while.
I am now trying to role back to before SSL, and am having a weird issue. Under http, I was using port number 123 (for example). I changed this to use port 443 (in order to use https).
After uninstalling the SSL cert and rolling back the Raven.Server.exe.config file (so Raven/Port is now set to 123 again), and load the studio, I get a 503 Service Unavailable error. The weird bit is, if I now change the port number to 122 (or anything not 123), the studio loads fine under http. It's as if that port number has been destroyed or something.
My question is this: What the flip is going on and how can I fix it?
By the way, I can't just change the port number, that would involve getting my whole team to change it on their dev environments.
An example of my Raven.Server.exe.config file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="Raven/Port" value="123"/>
<add key="Raven/DataDir" value="~\Database\System"/>
<add key="Raven/AnonymousAccess" value="Admin"/>
<add key="Raven/HostName" value="ravendb.mydomain.com" />
</appSettings>
<runtime>
<loadFromRemoteSources enabled="true"/>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="Analyzers;Plugins"/>
</assemblyBinding>
</runtime>
</configuration>
You need to do:
Raven.Server.exe --uninstallSSL
Related
I created a webapp with blazor serverside with a scheduler in my app using Hangfire. It's hosted in a IIS 8.5 on windows server 2012.
I already did all the settings to make sure my blazor app dont stop and dont recycle (idle=0,startmode,Regular Time Interval...) so the sheduler is always running. And all work good.
But if there is any server reboot, i need to restart my Hangfire server to restart the sheduler inside the app (just with single ping of the url in a browser)...
Like we can see on the screen, the hangfire server dont start until i ping my blazor's URL in a browser...
So you implemented all steps outlined in the hangfire documentation including preload and applicationInitialization?
Step 5 is persisted in the web.config of your application. To make sure it is not overwritten on deployment, one can put a web.config with the respective configuration under source control.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
<!-- Add this node to web.config -->
<applicationInitialization doAppInitAfterRestart="true">
<!-- Only needed when website contains multiple child apps -->
<add initializationPage='/hangfire',hostname='' />
<applicationInitialization />
</system.webServer>
</configuration>
Finally, if you use the app_offline.htm during deployment either directly or indirectly through the Azure DevOps Pipelines deploy task, then after the app_offline.htm is removed, only the next request restarts the app. In that case you need to fire a warm-up request manually. You can use a more elaborate warm-up script or this one-liner in your deployment pipeline.
curl https://my-page.com/
I think this is primarily an IIS thing, and what you want is to set the Application Pool in IIS to AlwaysRunning, so instead of starting up the worker process on the first web request it starts the worker process as soon as IIS starts.
See this SF answer
I configured IIS ApplicationInitialization as recommended in the documentation
add initializationPage='/warm-up'.
I implemented a /warm-up endpoint on my app deploy it to both staging and production slots.
When the app starts/restarts/swap the endpoint is NOT called because I can't see it in the logs.
When I hit the endpoint manually, it works fine!
What I'm trying to achieve is:
When I start/restart/swap my app
I want a page (/warm-up) to be called in order to preload the app
So the first call from a real client doesn't have to suffer from the app loading time
Currently, I implemented a service that runs when the app starts (IStartupfilter)
But the app, hence the filter, is not running before a first request hits the server!
So I want to hit the server instance as soon as possible with appInit
We have more than 5 instances at some time of the day
initializationPage is an IIS thing, it will not help you start up the ASP.NET Core application before the first request hits.
Instead, what you will need to do is configure the Application Initialization Module for ASP.NET Core. According to this documentation, you will need to enable the IIS Application Initialization module (which you probably already did if you could configure the initializationPage) and then modify the generated web.config to include the applicationInitialization node to the webServer section:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
<applicationInitialization doAppInitAfterRestart="true" />
</system.webServer>
</location>
</configuration>
This should start the ASP.NET Core application as soon as the IIS website starts, so there should be no delay. You will not need an initialization page then and can just initialize the ASP.NET Core application as the host starts.
I've read many similar issues but none of the resolutions solved my problem. So, here is my case.
I have a NET Core 2.1.1 app that runs beautifully within VS2017 and when published to my desktop running Win10 Pro and IIS10, i.e. running it outside of VS2017. But, when I deploy the app to a remote server Win2012 R2 with IIS8.5, I get the following issues with it.
I have followed different pages on deploying net core apps like this one.
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/index?view=aspnetcore-2.1
When attempting to reach the site I get error 500 Internal Server Error.
IIS manager complains about the generated web.config when clicking on any of the site's settings e.g. Net authorization, Net Error pages etc...
Even when setting the stdoutLogEnabled to true, I don't get any log files. I even tried adding custom details flags in the web.config yet still nothing changed.
This is the generated web.config, and I hope someone points me in the right direction.
Thanks.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\eSignWebMVC.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>
</location>
</configuration>
<!--ProjectGuid: 72897161-bbbb-4f20-a12c-7f33922ea6bc-->
So I finally got this to work and I HAD to install the latest bundle v2.2.2 even though my app is targetting Net Core 2.1.1, but Microsoft's horrible technology still didn't make the app to run with the 2.1.1. bundle. Total waste of time and effort on such a stupid thing!!
What's the meaning of still providing the prior bundles if none of them does anything?
In preparing to move some applications to IIS 8, I am getting hresult:c00cef03 error on Windows 10 and Windows Server 2012 R2 when using appcmd.exe or inetmgr to make changes to web.config as long as the web.config file contains runtime/assemblyBinding element.
Has anyone seen this before and what is the workaround?
Below is an example of appcmd output:
C:>C:\Windows\System32\inetsrv\appcmd.exe set config "Default Web Site/Configuration" -section:anonymousAuthentication /username
:""
Applied configuration changes to section "system.webServer/security/authenticati
on/anonymousAuthentication" for "MACHINE/WEBROOT/APPHOST/Default Web Site/Config
uration" at configuration commit path "MACHINE/WEBROOT/APPHOST/Default Web Site/
Configuration"
ERROR ( hresult:c00cef03, message:Failed to commit configuration changes.
)
The following is the content of a web.config file that you may use to reproduce the issue. It seems that just the presence of element would make the error happen, the identity of the assembly does not matter.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="true" userName="IUSR" />
</authentication>
</security>
</system.webServer>
<runtime>
<asm:assemblyBinding xmlns:asm="urn:schemas-microsoft-com:asm.v1">
<asm:dependentAssembly>
<asm:assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<asm:bindingRedirect oldVersion="4.5.0.0-9.0.0.0" newVersion="9.0.0.0" />
</asm:dependentAssembly>
</asm:assemblyBinding>
</runtime>
</configuration>
This is not a real answer.
I don't have access to Microsoft source code, but maintain an IIS Manager clone. So after reading your description I went on and investigated. My conclusion so far is that <runtime> tag cannot be easily processed via schema files. (That's why there is no existing schema files to handle it, different from <system.web> items, which have their own schema files).
The solution I gave to Jexus Manager is a new commit, where by reading machine.config the <runtime> tag is being ignored.
I can only guess that IIS Manager in IIS 7.0 and 7.5 also uses the same trick to ignore <runtime> tag. But the developer might have hard coded System.Configuration.IgnoreSection for .NET Framework 2.0, which won't work for .NET Framework 4.0 and above, and can possibly lead to the you met. One supporting fact is that for IIS 8.0 and above, IIS Manager (and MWA API) runs fully on .NET Framework 4.0, not 2.0 any more.
Well, at this stage you can only report this bug to Microsoft and hope they can fix it. And if they don't want to fix, you almost have no choice but use workarounds, like
Removing the <runtime> tag before calling IIS API, and adding it back when finished).
Unfortunately I don't have enough time to develop a appcmd clone based on Jexus Manager code base. Otherwise, that can be an option for you to try.
Microsoft suggestion is to remove the XML namespace prefix from assembly binding elements, which I have verified to have solved the problem. Although it is less than ideal for correct XML syntax to be rejected, this is an acceptable solution.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="4.5.0.0-9.0.0.0" newVersion="9.0.0.0" />
</dependentAssembly>
</assemblyBinding>
I have recently published my ASP.NET Core application to my host. I am hitting a HTTP Error 500.19.
IIS 8.5 says the issue is:-
"Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'aspNetCore'"
It also highlights this key add line in my system.webServer config:-
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule"
</handlers>
I'm not really sure what to do on this. It looks as though there is a duplicate instance of this, so I have tried renaming this but it still asks to add this again?
Here is my web.config:-
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!--
Configure your application settings in appsettings.json. Learn more at http://go.microsoft.com/fwlink/?LinkId=786380
-->
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>
</system.webServer>
<system.net>
<defaultProxy useDefaultCredentials="true" >
</defaultProxy>
</system.net>
</configuration>
The answer above didn't work for me, however DavidG's comment did solve my problem, so going to post as an answer in case it helps someone else.
For me, I was not running it as a sub-application, and a project that had been working for me no issue for over a year suddenly stopped working with this issue. Still not sure what changed. When I commented out or removed the <add name="aspNetCore".../> the error persisted, and then that line got automatically re-added.
To solve the problem, I added <remove name="aspNetCore" /> to the config file, right above the <add name="aspNetCore"... /> entry, and things started working again.
To continue running on IIS EXPRESS, go on root folder where the .sln file stays.
go to delete file from .vs\config\applicationhost.config or save
it in a temporary place if you have something there.
Close/Re Open VS Studio, run again, will work.
If you need to add something back from save applicationhost.config, just compare those two, but I don't see what you could have there.
None of the suggested solutions worked for me unfortunately. By some miracle I learned that my applicationhost.config file had been modified in an unfortunate matter, making that "Cannot add duplicate collection entry" error appear when I navigated to a specific page in my .NET Core website application.
Under the <sites> tag in applicationhost.config, I had the following:
<site name="MyWebsite" id="2">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:\Users\___\solutionname\MyWebsite" />
</application>
<application path="/SomePage" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:\Users\___\solutionname\MyWebsite" />
</application>
<bindings>
<binding protocol="https" bindingInformation="*:12345:localhost" />
</bindings>
</site>
The 500.19 HTTP error was shown to me when I navigated to the page "/SomePage". As you can see, for some reason there was a separate <application> tag for this specific page. I have no idea why.
I removed that entire <application> tag for the "/SomePage" path, and everything started working again.
I faced this issue with vs 2017 on a project that was working fine without changing the web.config. Looking at this posts I realized that it might be an IIS express issue and I solved simply deleting .vs folder and restarting vs.
I had the same problem and in my case commenting the line
<add name="aspNetCore"...
solved the issue and brought up the question "why is it working without AspNetCoreModule".
The problem in my case was that I was adding the site as a sub-application in defaultwebsite and it was located in the wwwrootfolder. I think the config was automatically picked up by the defaultwebsite and applied for all sub-application sites.
This link helped
So the solution was to move it as a separate site on another port.
In my case, the issue was caused by putting a path in the Debug Tab of my web project so that the app would open at a particular page. This causes two silent additions to the file .vs\config\applicationhost.config, similar to the one observed by eightx2.
In :
<add name="api AppPool" managedRuntimeVersion="" />
In :
<application path="/blah" applicationPool="api AppPool">
<virtualDirectory path="/" physicalPath="your-path\src\your-proj" />
</application>
where a similar entry already exists. This is the root of the problem.
The error message, unfortunately, is completely misleading.
Solution is to rename applicationhost.config, restart VS, and let it rebuild the file. This is why Ricardo's solution of deleting the entire .vs folder also works.
That error is because there is a root file in ASP.NET Core that is called ".vs\config\applicationhost.config"
Initially it has 67 keys. You can see it for yourself here, in the Configuration Editor.
This file called ".vs\config\applicationhost.config" has the default settings carried by the Web.config to be able to work, and one of them is that handler.
You can also see it here.
The problem is that that file has that handler and what you publish is going to inherit that handler.
You have two solutions, comment on the line of your published web.config or delete that handler from the ".vs\config\applicationhost.config"
I just had this one, it turns out I had changed the App Url in Debug settings for the website Properties, in order to load a specific page (wrong but happened).
In IIS it automatically created a new application under the test domain called About (in this case).
Removing the rogue IIS application under the domain solves the issue as it doesn't attempt to reload the same web.config when navigating to the page.
I commented the below statement
<verbs allowUnlisted="true">
And its works
If you're running your site in IIS, check if your Application Pool has a "duplicate" Application attached.
I had this same problem debugging my site in IIS. While troubleshooting I found that the Application Pool for my site showed 2 applications connected to it. I checked each of my sites to make sure I hadn't accidentally assigned one of them to the same app pool but they were all correct. So I deleted my site in IIS and checked the app pool which then showed 0 applications. I recreated the site in IIS, attached it to the application pool which then showed only the 1 application. Restarted the site and it worked correctly.
Not sure how that phantom application got attached to my app pool but that's what was causing the duplicate aspNetCore key in my case.
I have a parent web application with multiple child applications.
This is what worked for me:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments="<pathToDll>" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
</system.webServer>
</location>
</configuration>
Basically, wrap the system.webServer element of the parent website with the location element and set inheritInChildApplications: <location path="." inheritInChildApplications="false">.
Then the child websites can stay the same and you do not need to add <remove name="aspNetCore" /> to each child website's web.config.
Note that this is in the project file:
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
And it gets changed to this during publish:
<aspNetCore processPath="dotnet" arguments="<pathToDll>" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />