I would like to ask if it is save to publish .net core web project to production IIS server directly through WebDeploy or Folder publish profile.
What about already running http requests ? Would it be better to stop the IIS website first, update codes and start website again ? But I don't know if stopping the IIS website will wait for running http requests or stops them by force. Does the publish profile handle this by default (for example it happens often with folder publish profile that files are being in use by IIS process and the publish operation fails) ?
What is your publishing process, do you stop the website instance ?
The configuration file will be saved when directly publishing the .net core project to IIS.
When publishing a .net core application, the web is not running in iis, but as a separate out-of-process console application, using Kestrel components. AspNetCoreModule is hooked to the IIS pipeline early in the request cycle, redirects all traffic to the following Core application, and all requests are forwarded to the Core process.
Requests come in from the Web and int the kernel mode http.sys driver which routes into IIS on the primary port (80) or SSL port (443). The request is then forwarded to your ASP.NET Core application on the HTTP port configured for your application which is not port 80/443. In essence, IIS acts a reverse proxy simply forwarding requests to your ASP.NET Core Web running the Kestrel Web server on a different port.
So I suggest you stop the website while publishing and restart it then. Files in the deployment folder are locked when the app is running. Locked files can't be overwritten during deployment. I recommend that you take the original application offline when you publish a new web, which is also recommended by Microsoft. More details can refer to following documents。
Taking an Application Offline before Publishing.
Locked deployment files
Related
I'm developing a Web App with Dache, Thanks the author for the fantastic library.
Unfortunately, I have a big problem with it.
In previous version of 1.5.6, it was worse. but in 1.5.6 it's better but still I get The following exception:
There are no reachable cache hosts available. Verify your client settings and ensure that all cache hosts can be successfully communicated with from this client.
In developing, I get the exception after 2 or 3 times build, and I have to restart cache service and stop IIS Express to remove the exception.
In the web app after some hours the clients disconnect from cache service. and I have to restart the cache service and web sites to remove the exception.
I hosted dache on windows service.
I think the problem is for comunications between dache host and dache clients.
So, Is it possible to host dache cache on IIS like a WCF service instead of windows service?
You can host Dache in your own process using the Nuget package. More information available on the Dache wiki:
I've created a streamed wcf service based on that example: http://www.codeproject.com/Articles/112655/Progress-Streamed-File-download-and-Upload-with-Re
With console host works everything fine, the upload and the writing run "parallel". But if I host the service in IIS, it seems, that the stream is buffered on the server side.
Why? What is the difference? Is the service with console host not reliable?! (I need reliable streming!)
How can I avoid that with IIS host?
How do you know its buffered? Check the config file on the client side after proxy generation. Sometimes the proxy generated config file has incorrect transfermode.
When you start writing the file on the client, don't any see any chunk wise increase in the size of file?
The hosting shouldn't affect the transfermode.
The only difference between IIS and Console would be the way activation/deactivation is managed.
I've found it: Getting Streaming in IIS Hosted WCF service to work
I think this is a known issue (streaming with .net 4.0 and iis 7).
When a WCF service using streaming is hosted in IIS then ASP.net
buffers the request at its layer. The request does not even come up to
WCF until ASP.Net is done with it.
This should work when using non-HTTP transport IIS or hosting in a
non-IIS host.
(Zulfiqar Ahmed)
on contacting the product team - they said it would be fixed in .NET
4.5 as its too big to be issued as a patch.
And it works with .NET Framework 4.5
If I run a WCF application which exposes a service in visual studio, is it possible to consume the service from an asp.net application running on another computer? How can I determine the address of the WSDL published by the WCF service in order to add a reference to it in the ASP.NET application?
If your service is an ASP.NET application and you are hosting it with the built-in development server, refer to Kalus's answer. However, if you have IIS installed locally, you can reconfigure your project settings so that the application is hosted by IIS for debugging instead of the built-in development server.
If you are writing a standalone WinForms or Console application, then the responsibility will be on you to select an endpoint and binding, whereas with an ASP.NET application, those parameters will come from IIS or the Dev server (the protocol will always be HTTP/HTTPS, and the port number will be set by IIS or randomly generated by the Dev server). So in a standalone application, you will have to configure which binding (basicHttp, wsHttp, netTcp, etc.) and an appropriate hosting endpoint (http://hostname/MyService or net.tcp://hostname:port/MyService). But yes, if the service is hosted by a standalone application, it will be accessible from other computers.
Refer to this overview here: http://msdn.microsoft.com/en-us/library/ms731758.aspx
According to #Kent Boogart's comment below, the asp.net development server can only be used for local requests. So you will need to configure your web service to run in IIS if you want to call it from another machine.
I'm in the process of deploying a WCF service application. The service works fine if it's running as its own site, but the intention is for the service to run as a virtual directory of the Default web site of the server. When I set the service up in this configuration, I get an odd problem. When the client tries to make a service call, it receives the HTML of the friendly service description, not SOAP. Naturally this generates a service error. The HTML appears to be identical to the service page that you see in a browser with an HTTP Get, but I'm only seeing the first 1024 bytes in the error message, so I may be missing something.
I've checked HttpHandlers and loaded assemblies, and as far as I can tell there's nothing unusual that is being inherited by the virtual directory. The default site has 3 ISAPI Filters installed including Outlook Web Access (yes, this server is running Exchange). I tried installing these filters in my test web site, but it still ran the service without problems. The problem only happens with the service is running as a virtual directory of another virtual directory within the default web site.
The server is Windows Small Bus Server 2003 SP 2 running IIS6.
If you're hosting WCF in IIS you need to set the server up in the 'Application Role' check out the following link does that help:
MSDN: Internet Information Service Hosting Instructions
I have to do some maintenance on a WCF service that is hosted in a managed windows service.
In the old deployed version I can enter: http://localhost:9091. It shows a page with info about the hosted WCF service (with a C# and VB example).
When I get the sources from TFS and reinstall with the MSI, the same http://localhost:9091 gives a 404.
What could be wrong ?
Could be lots of things. Try these for a start:
Installed msi on wrong port
web site / app pool not runnig
the configuration in web.config does not match the new location
Web site not marked as asp.net 2.0
IIS not configured to recognise svc files
The last 3 are the most probable. Check the event log for more details.
Here are a few more based on the comment:
is the service started
is the port blocked on the new machine
the configuration in web.config does not match the new location
Perhaps that port is meant to be the port of the ASP.NET Development Server. Is the service started? Open the solution in Visual Studio, right-click the service and choose "View in browser". That will have the side-effect of starting the service.