I have an Asp.Net vNext site that I want to connect to a Silo. The vNext site is already done and in production, but the silo part isn't started yet. I'm just in the planning phase, so now's the time to just scrap the whole idea if it seems crazy. Is this even do-able?
I know that you can create a Virtual Network to connect your web app to your Worker Role, which seems simple enough. But, I'm not sure what my server and client configuration should look like, especially around using/discovering DeploymentIds.
The Orlean's provided AzureClient throws an exception when I try to use it in the vNext site -- something about an Azure-related type not being marked Serializable. In the vNext site, I can get the normal SiloClient to work by manually providing the DeploymentId. In my dev environment, the DeploymentId changes each time I debug, so this obviously isn't going to work.
Does anyone have any advice to point me in the right direction here? Let me know if you need more information, and I'll be glad to provide it you.
Where are you hosting your vNext site ? Is it inside webrole or Azure App?
Orleans Client and Silo can't be run in the same App domain so the simplest way to run it in a separate worker role ( it also allows you to scale silos independently)
Related
I finally got my ASP.NET MVC application hosted on my local Windows/IIS server. I went to the login page but when I try to log in it says,
Error:
An error occurred while processing your request
This is fairly non-descript...
My gut feeling is that when I did the web deploy, I didn't deploy the localdb(?) where the users' credentials are stored. Before I try to re-deploy the entire app, I'd like to see if anyone can offer some guidance. Am I on the right track? Are there other possible causes/solutions I should investigate?
I'm using the default registration/login system that is in the project to start with, and it woks just fine in VS. I did a regular web deploy to my IIS server, and the site works just fine until you go to log in.
Fixed: This issue was caused (as suspected) by the inaccessibility of the LocalDB where all the users' credentials are stored. VS uses this light DB instead of making you install SQL Express or another alternative (much like IIS Express works better for debugging than full IIS). When I push my application to IIS from VS, the database wasn't connecting. I eventually found this other SO question, and the top answer fixed my issue.
How to deploy ASP.NET MVC 4 application using localDB to local IIS on Windows 7?
This will solve the issue, but there is a lot of conflict on the web as to whether or not it is ok to use LocalDB in production, so if you have a lot riding on your project you might want to take a look at that. For my purpose, LocalDB is just fine, so this solved the issue. Thank you to all who responded to my (admittedly) broad question. I'm sure this will be a useful thread for others with the same issue.
I'm pretty new to ASP.Net and I've been having troubles understanding something.
I made a web application project with a web service on my computer.
I made another web application project, who then consumed the WSDL from the web service on the first project and uses a function in it.
I ran each on a different VS2012 Instance and when both projects are running in then there is no problem and it works fine.
When i close the VS Instance with the Web Service project then I get a Coonnection Error which is also logical.
My question:
Is there a way to keep the server running without keeping visual studio open?
There is no ".exe" generated or anything so I don't know what to run in order to keep the "Server" running..
Additional question if you don't mind:
If I want to use this service from another computer on the same Network, will the "localhost:.....?WSDL" service reference still work or do I need another address?
Sorry for my lack of knowledge, I just couldn't find a good guide explaining about how to keep the server running anywhere.
Thank you, Mellor.
Host your web service in localhost
use the computername instead of localhost in WSDL URL when you add services/web reference in cleint applications
When I get a call there was an error in our web application when running on a windows server I would simply go to Windows Logs and scroll down the application logs and find the Warning. Easy to read and made it quick to solve the problem.
Now I'm testing out Azure Websites to run asp.net applications and i'm racking my brain trying to figure out how to have the same kind of quick error find a fix process.
Viewing the application logging in Azure's application diagnostics is utterly useless.
It would take me forever to dig through those logs. rewriting the application to handle errors differently is not an option for me.
So who else is having this problem? any solutions?
The easiest solution is to offload your error logs to a separate service like Raygun. This will result in a (small) monthly fee but is a 5 minute setup and you are good to go.
Otherwise you can go and use Log4net to log your error to the blob storage but then you will have to poll that one for your logs.
Try the Azure Website Log Browser site extension, you can install it from the new Azure Portal on your website (as a site extension) and it makes it easier to view all of your logs.
Read more about it here.
Usually I would look at writing a Windows Service to manage tasks that aren't suited to being hosted in a web application. These types of tasks are usually long running processes or scheduled tasks. Although this is normally the primary approach for these types of tasks, people have looked at ways of running these kinds of background processes in a web application by kicking off a number of threads in the Application_Start event exposed by Global.asax. The problem with this approach has always been that if your IIS worker process dies, then your background thread is killed too (effectively your 'Windows Service' is stopped until the next request is received).
ASP .NET 4.0 offers a solution to this problem. You can now set the StartMode to 'AlwaysRunning' as described in this blog post by Scott Gu. Somewhere in the comments on this post, someone asks a question about the viability of hosting Windows Service type tasks in IIS since the new feature ensures the worker process is always running. Scott mentioned that it would definitely support the scenario. Further to this, the recent introduction of AppFabric means that Microsoft themselves are providing simple hooks for hosting and monitoring WCF and WF services in a web application.
What does this mean for those of us that used to write Windows Services to support our web apps? Should we adopt this model? What are the pitfalls? As far as I can tell, there are a number of benefits to hosting 'Windows Service' processes in a web application, the most useful being the ease of deployment. Furthermore, we can actually start developing simple user interfaces to our services which provide information about what is happening at runtime.
If I had to go this route, I don't think that I would host my 'Windows Service' type functionality in the customer facing web application. I would probably develop a new web application project (much like I would in the Windows Service context) that would host my long running/scheduled task processes. I guess there are few reasons for this.
Security. There may be a different security model for the UI displaying information about the running background processes. I would not want to expose this UI to anyone else but the ops team. Also, the web application may run as a different user which has an elevated set of permissions.
Maintenance. It would be great to be able to deploy changes to the application hosting the background processes without impacting on user's using the front end website.
Performance. Having the application separated from the main site processing user requests means that background threads will not diminish IIS's capability to handle the incoming request queue. Furthermore, the application processing the background tasks could be deployed to a separate server if required.
I would be really interested to hear your thoughts on this approach and whether I should be sticking with Windows Services. I am very tempted to try this new approach.
What does this mean for those of us that used to write Windows Services to support our web apps?
I think this a key scenario where you could be move away from a Windows service to using the continous running web site.
Should we adopt this model?
Standard development answer: Depends ;)
What are the pitfalls?
One issue I can see is the IIS dependency. If you need a service to run on a users machine I would not feel comfortable about asking them to install IIS just to run my service. Here I think the traditional model works better.
Monitoring and tracking are major issues, but as you also point out this is solved by AppFabric. It is even better than what you get from the Window Service. However you have added another dependency which also will require .NET 4.0 and a relatively new version of Windows. I could also be wrong here, but my understanding is that AppFabric is not supported in production on client OS's. Which could bring in additional headaches.
You will lose pause functionality in the continuous web site model too.
Finally IIS killing inactive app-pools isn't the only way an app pool can recycle. Editing a web.config file causes it for instance, which may not be an ideal situation.
the most useful being the ease of deployment.
I also think development is much easier - in the past I have had a console app and a windows service so I can dev/test on my machine using the console app and then change it to a windows service when it goes out. Now dev/test is MUCH easier.
A must read for this is Death to Windows Services...Long Live AppFabric!
What are the pitfalls?
One I found, no shutdown event. You have AppStart when the web site starts (not global.asax because that is HTTP only) but you have no way to handle shutdown which could mean disposing becomes an issue.
I would suggest sticking with a windows service. The issue is with your number 2.
You won't be able to update service part of web site without restarting whole web site.
I'm developing a web site in a high-security environment. For example, we use CAC cards to authenticate users over SSL.
The site is a mix of VB.NET and C# on .NET 3.5 with some AJAX. The AJAX parts are now calling web services for things like Cascading Drop Down Lists.
We've been running VS2008 configured on our local PCs to use IIS instead of the default server (Cassini). However, some security policies were rolled out to the desktops over the weekend and, suddenly, we're not allowed to run IIS on our PCs anymore.
I already have some of our IT people trying to appeal for waivers for developers. In the meantime, I need to find a way to keep developing.
If I turn off the SSL requirement to the 'secure' part of the application (locally, my PC only) I can serve up some of the pages (using Cassini) when I hit "F5", but pages with web services just bring up "server application unavailable".
I need to be able to add some more functions into the existing web services, among other things, so the ability to single-step through the code is still a necessity.
I'm sure someone who is limited to using Cassini has found a way to Build/Debug pages in VS2008 when webservices are involved.
Thanks in advance.
EDIT: As it turns out, some links had "HTTPS://" hard-coded in them (I inherited these). Changing the link to "~\folder\page.aspx" allowed Cassini to properly serve things up.
Note that using Cassini is the default for VS2k8, even for Web Services. Try starting a new HelloWorld web service project and confirm if you can debug it.
OK So that worked. Then change the debugging options of your real project back to using Cassini rather than IIS. I wouldn't move the project (although backing it up might not be a bad idea) as you might be able to get IIS working again.
EDIT: So your actual problem wasn't to do with web services, just hard-coded URLs. (We have similar problem where much of the site works where ever the root of the website is, but some places, such as "main menu" links, expect the root to be the root of the webserver.)
You proabbly need to contact your IT department and have them open up something on the network so you can call the services - a port on a firewall, for instance.