This question has probably less to do with actual programming and more to do with environment setup.
I'm developing an application for a Windows CE device, which will use a service hosted in Microsoft Azure. Obviously, this is all under development, and the service itself has not yet been uploaded to Azure. So I'm using the emulators provided by MS to deploy the service locally. Also, I don't think uploading the service to Azure just to debug it is a good idea, as that could net us a bill for Azure we don't yet want to pay.
Also, please note, I'm using VS2008 for the Windows CE project and VS2010 for the Azure project (thank you MS for dropping support for mobile devices -_-).
The problem is, the service seems to be accessible only via 127.0.0.1 or localhost, and if I physically connect a Windows CE device or use an emulated one, it becomes a new entity on the network, and cannot access that service any more.
How can I debug my Window CE application and have it see the service, whilst still being able to debug the service itself?
You are correct, the development fabric (the compute emulator that allows you to build an azure application and debug it locally) is only meant for local development. There are some hacks that allow you to get around that, but I wouldn't recommend it.
My recommendation would be to spin up the service in a more traditional hosting environment, at least in these early stages. You can define it as a web app just as you always would have, and get it functioning. Then, when you know its mostly complete, create a cloud service project and do an add existing to bring your web app into the cloud service solution. Once in, its a simple matter to add the web app as a web role.
From there, you can complete testing of the service in both the local and hosted azure environments as needed. This allows you to minimize your development costs while still leveraging the power of the cloud. As an upside, you also have done most of the basic work to ensure your service is compatible with multiple deployment scenarios giving you a greater degree of choice for its final production state.
OK, I don't know if this was intentional, or if I found one of the mentioned hacks, but I saw that IIS hosts the Azure site I created on port 5100, and the binding for this site is *, so it accepts all connections.
Using this I could access the service from my emulator, and I could still debug all Azure related stuff.
Related
I've created a simple Stateful Actor and a Web API (self hosted) and deployed it to Azure. It has worked and I can browse the nodes in the Service Fabric Explorer.
Azure gives me a url but when I add /api/values to the end (which works fine locally) it downloads a file called values and I can't open it as it is a binary file.
I want to call the web api from a Xamarin app (ie normal Rest api call) but if I can't call it via a browser I'm a bit stuck.
I would comment this on Stephen's answer, but I lack sufficient reputation.
To add a custom port to the Load Balancer after the service fabric cluster has been created you can (in the newer Azure portal):
Navigate to the load balancer resource for your service fabric cluster.
Under "Settings" find the "Load balancing rules" option.
This will have at least two rules, more if you did setup custom rules during the setup of the cluster.
Add a new rule.
Give it a name
'Port' is the external port you'd like to hit.
'BackendPort' is the port your service is configured to listen on.
The defaults on the other settings work in a pinch.
Note if you have multiple ports to enable, they each need their own rule.
I do know the above worked in my 'hello world' sandbox project.
I'm climbing the service fabric learning curve myself so I can't comment with authority on the other settings.
Have discovered what was missing.
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cluster-creation-via-portal/
This link here walks through creating the Service Fabric app on Azure and in particular the field "Application input endpoints" needs to have the port you want to use. For the samples, they are mostly port 80 or 8081.
There is supposed to be a way to add these ports afterwards which I tried (and so did a Microsoft support engineer) and it did not seem to work. You are supposed to be able to add these ports to the Load Balancer associated with the Service Fabric App.
I recreated my Service Fabric app, exactly as I did before but this time filled in the ports I want to use in the Node Type section and now I can hit the webapi services I've deployed. This field can be left blank which is what I did first time round and was why I had issues.
Not really related to Service Fabric, it's just how you set up your HTTP response headers in Web API. Recommend tagging this with asp.net or asp.net-web-api for a more thorough answer.
Tutorials and technical resources around Azure Service Fabric Stateless Web API tend to be slightly disjointed, given that the platform and resources are still quite immature.
This Stateless Web API tutorial, at the time of writing, is very effective.
As prerequisite to the tutorial:
Update Visual Studio to the latest version (Extensions and Updates)
Update the Service Fabric SDK to the latest version (Web Platform Installer)
Explicitly specify the EndPoint Port attribute (defined in ServiceManifest.xml) when setting up your Azure Service Fabric Cluster Node Type parameters
Following these steps will successfully allow deployment to both local and remote clusters, and will expose your Web API endpoints for consumption.
Currently, my visual studio solution has 3 projects:
MVC project - to be deployed at say www.something.com
Web Api - to be deployed at api.something.com
SPA application - to be deployed at app.something.com
Will I be able to host all of these just through VSO source control? I am not sure if azure would be able to host the applications at respective sub-domains without explicitly defining them?
Can anybody please clarify? And what would be the best approach?
if you host your application on Azure App service, there is continues deployment service. You can have your code next to your site (Local Git https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/) or you can have your code in supported repository e.g github/bitbucket etc ..
And Azure App Service supports virtual directly, you can have multiple apps in the same site. see detail answer from here Publish Multiple Projects to Different Locations on Azure Website
Hi,
My application is in Asp.Net MVC3 coded in C#.Net. I have published my solution and deployed it on IIS on the client machine. For this particular client we are not using any online server, we have published on client's local machine on IIS and from that machine only they will use it. The only problem we are having is regarding the security of the application as our client is accessible to the database as well as the application.
So under this scenario any technically aware person can take the published copy of the application and publish it again on their machine.
My query
How can i prevent the user from redeploying it on any other machine. Something like we have in the desktop application where the IP of the machine is taken and that particular application can run only on that machine.
I want my published content to be used only on the machine im have published and if the user wishes to copy the published content and deploy on other machine then it should not happen.
I have googled a lot regarding this but no result is returned in this regard.
Suggest how can i achieve the same.
Yes you can secure your ASP.NET MVC application to run on only 1 computer. Here are some companies that offer copy protection:
DeployLX by Xheo (http://xheo.com/)
Cryptolicensing by LogicNP Software (http://www.ssware.com/cryptolicensing/cryptolicensing_net.htm)
IntelliLock by Eziriz (http://www.eziriz.com/intellilock.htm)
ElecKey 2.0 R8 by Sciensoft (http://www.sciensoft.com/products/eleckey)
I recently installed Windows Server Service Bus 1.0 (on a Windows Server 2008 R2 machine).
That also installs "Windows Fabric" (not AppFabric).
Could not find much information on it, and googleing it I stumbled on a Lync server post (Windows Fabric is also installed by Lync Server 2013).
Definition:
"Windows Fabric is a Microsoft technology used for creating highly reliable, distributable, and scalable applications."
From the Service Bus architecture intro,it looks like Fabric is what allows for services replication, high availabilty, and fault tolerance.
Anyone knows if that can be used to host custom .NET services? Or any kind of direction would be greatly appreciated.
Thanks in advance.
Cos
I went to a talk by Mark Eisenberg on May 28th at the Microsoft NERD Center near MIT in Boston MA. The talk was mostly about the Azure Service Fabric. General consensus was that if you're using Azure from the infrastructure as a service perspective you aren't really using it.
The next step up is to use Azure naively as a platform meaning that rather than create VMs and hosting them there you're creating cloud services and web jobs and web apps and using the new Logic Api's etc...
But if you really want to build a stateful, resilient service enterprise class you'll want to go underneath the PaaS and write against the Service Fabric directly for greater control.
That's where the money is.
I did a write up on the talk and what the Azure Service Fabric is a few days ago and posted it here.
I don't actually think that Windows Fabric is open product. It is used for infrastructure purposes, and not for deploying custom services. For your custom services you have to use platform built on top of Windows Fabric, like Service Bus, Windows Server App Fabric.
I think Windows Fabric is for internal use by Windows Azure and Private Cloud for clustering, load balancing and so on.
UPDATE:
I've started developing Windows Azure application and here is what I've found.
I've added a Service role to Azure application and started it on local development machine (under Azure emulator). And my service was published in and started under Windows Fabric!
So the conclusion is: Windows Fabric is a platform for running YOUR Cloud Services.
Fabric which the name suggests in itself, is back-end.
It is no different than iSCSI or EIGRP. The main difference is that it is generic in form rather than specific like the aforementioned services/protocols.
IIS is a server service specific to web hosting.
SQL the same but database only..
fabric, applied to host fabric aware services and software.
Windows Fabric is used internal by Microsoft to building highly available, resilient and scalable services. It has been used for Service Bus, SQL Database, Document DB etc. according to this video: Building Resilient, Scalable Services with Microsoft Azure Service Fabric
Until now it has not been available for external parties but has now been announced as Service Fabric which will be available on Windows Azure and Window Server 2016.
Read more here: http://azure.microsoft.com/en-us/campaigns/service-fabric/
I am kind of new to system architecture. That is, all of my web apps have been relatively flat...two machines at the most running web client and database.
I have been handed the following architecture:
1 VMware machine will run the web application, an MVC 3 app.
1 VMWare machine will host the SQL Server database
1 VMWare machine will host the services.
The machine I'm confused about is the last one. From what I understand, the services project contains references to three other projects: the model, where the entity framework edmx resides, the entities project, which contains T4 templates that use the entity edmx file as input, and the business project which is where the actual business rules are implemented and the meat of the CRUD actions take place.
From what I understand, the intent is to not run an IIS WCF web services interface, but to make calls to WCF services (like those hosted in the MMC services snap in) on the machine over the internet. There is a deployment project in the solution for the services project but I don't know if it's configured properly. I think the idea is to just run the installer on the services machine and it will work.
My specific question is if there are any important things that I need to keep in mind when implementing, configuring, and deploying these services?
I'm kind of new to all of this. I was under the impression that you had to make calls to WCF services via IIS hosted endpoints and that you couldn't (or it at least was inadvisable) to make what amounts to RPC-like calls to machines over the internet.
Since you are new to WCF services, I suggest reading this MSDN article on Hosting and Consuming WCF services.
From what you describe, it looks like you are using Windows Service as a host for your WCF service.
The most common choice for a host is IIS because of its extensive features including self-starting services, ease of deployment, load balancing and so on.
Windows Service is a valid host, provided you can justify the question 'Why not IIS?'. Maybe, you need full control over the activation and lifetime of your WCF service. Not sure.
p.s. Ensure the account that your Windows Service runs under, has the minimum privileges.