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:
Related
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
This has to be a pretty simple task. I have an Azure Cloud Service that works just fine with HTTP and HTTPS. Now I want to create a net.tcp connection to the cloud service. The first thing I discover is that net.tcp is not supported by IIS Express. That's fine. So I try switching to regular IIS and all I get when I try to run the application is a 404 error. If I was building an WCF Web Application, I would get a form that allows me to select (and build) the virtual directory for the application, but there's no analog for this in the Cloud Service.
I can take a fresh 'Cloud Service' project build using visual studio, make no changes to it except change IIS Express to IIS. When I launch it, I get a 404 error in the web browser.
Does anyone have a working example of tcp.net (with IIS Express or standard IIS) in a Cloud Service?
This video by the Azure team is a great overview and cleared up a lot of conceptual issues I had. An Azure Cloud Service is a container around one or more virtual machines. The virtual machines basically come in two flavors: Web Role and Worker Role. What threw me is the description that the Worker Role was intended for background processes: not true. A Web Role is basically a VM with IIS, a Worker Role is basically a VM without IIS. Since the off-the-shelf IIS doesn't have net.tcp installed, you have to jump through hoops in order to get the protocol installed. Instead, the Worker Role can be used as a self-hosted web service. If you want the performance and throughput of TCP, this appears to be the direction to go.
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
I have worker roles that send out multicast messages using the azure service bus. Two of the consumers of these messages are websites hosted on Azure. I know that there are issues hosting service bus WCF endpoints in IIS even when running on premise. I've followed the Microsoft's advice and configured a service host programmatically.
One of the websites has been using this technique successfully for quite a while. It uses the hosted web core (it was developed before full IIS was an option on Azure) and it initialises the service host as part of the RoleEntryPoint.OnRun(). I'm trying to move this site to using full IIS. Because in full IIS the RoleEntryPoint runs in a different process to the site itself and the service host needs access to some static variables in the site I've moved the initialisation of the service host to the Global.asax Application_OnStart. This code works fine when running as a website under IIS locally and it runs fine when running in the compute emulator, but once I deploy it to the cloud my WCF host never seems to receive any messages. I haven't been able to catch any errors that are occurring.
Has anyone else out there successfully deployed something like this?
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