We are developing client application for our solution. Its a desktop client. We are using flex for same. (Although I know flex is meant for web application and air application is best suited for desktop clients, but due to some build issues we can't go for air applications). Now according to our use case we required to read file from local file system which is not allowed in flex application due to sandbox policy. To override it we had planned to use it in local mode (i.e. running from local file system instead of deploying in web container). So after running application in local mode it bypasses sandbox policy and allows to read local file. Eventually we requires remote services call (either using web services or blaze ds) also in our application. To avoid sandbox restriction for network access in local mode we are planning to explicitly grant network access permission to our flex application. So does anybody finds any issues in this approach which I may encounter ?
Thanks,
Ankur Shah
As long as you make sure to use the local-with-networking security sandbox. This will allow you to access both the local file system and the network.
You can see more about the different sandbox types here: http://livedocs.adobe.com/flex/3/html/help.html?content=05B_Security_04.html
We had to avoid any of these kinds of issues by using Air with C# WebServices and HttpServices (twas an Air GUI with C# server-side running on Windows). Although not much help to you.
Another possible solution might be to use JavaScript within Internet Explorer to access the local file system via ActiveX controls (which I hav'nt done), and then use Flex's ExternalInterface API to grab the JavaScript/Html data from within the same browser (which I have).
Related
I've created an Azure server instance. I've deployed a simple application to it. As part of the deployment process I enabled Remote Desktop Connections.
I have some standard ASP.net applications that run on Windows, is there something to stop me deploying these applications manually to IIS using Remote Desktop. I've read so much about having to migrate standard ASP.net apps to Azure. I don't want to this as we will have customers who will still use Windows Server 2003/2008 so I don't want to have to maintain 2 versions.
Well, as I understand it, in theory you could deploy stuff using remote desktop. But when the instance shuts down/restarts you'll lose it all (unless you've built it into your startup scripts) and have to re-load everything each time. The main reason they suggest you have at least two instances is so that when one shuts down for updates etc there is always at least one other running.
The "Windows Azure Accelerator for Web Roles" project allows you to create an Azure web role which then enables you to use web deploy for all your other web sites - I'm guessing that will be a whole lot better approach and is definitely worth a look. Also, I believe smarx.com is a good place to browse for info and ideas.
Using a startup task and the Azure Bootstrapper you can download, unzip, install almost any kind of 3rd party software that supports either xcopy deployment (just copy the files) or an unattended(silent) install.
Assuming you aren't using Azure storage or anything like that, there shouldn't be any difference with the IIS application. If you are using anything specific to Azure, you can use the RoleEnvironment.IsAvailable to test if you are running inside Azure or not. That will return true for the emulator as well. If you want to use Azure storage from both, you can add the settings in the web.config to use if not running in Azure.
I have a dll i created that gets the excel object on users computer(if excel is installed) and has a handful of availalbe functions. I made a reverence to the dll in a Web Application. When I test this using the local host it works. If I deploy this on a Web Server will it still work or will it try to find the excel application on the server?
Without seeing your code I can only offer a guess, and my guess is that it will search the server and not the users computer.
You can probably use ActiveX to call Excel from the users computer, but that would only work in IE. I'm not sure who your audience is, but I needed similar functionality for the company I used to work for. For that I made a program that was installed to all users computers and then we used a custom http protocol that would open up programs on the client machine through a hyperlink. Doing it this way is cross browser compatible.
I currently work with a legacy asp.net web application and one of the requirements going forward is that it be deployable to windows azure.
I would like to know how difficult it will be to manage deployment to both Azure and a traditional IIS web server.
Azure seems to require a specific customized version of a web applicaiton project is it possible to deploy the customized web application to a standard IIS instance once it has been converted.
EDIT:
It is a ASP.NET Web Application rather than a Web Site (compiles everything into one dll)
UPDATE:
In the end due to the amount of work involved in converting the application to work in Azure and the cost of Azure compared with other cloud solutions it was decided to go with a traditional Cloud hosted virtual server.
And thank you for the really good answers.
Whether or not you can deploy your application to Azure almost as is depends a lot on how your application works. Azure pretty much requires your application be stateless. If it's a plain vanilla web application that stores data in the session or application cache only and saves data to a database only, then you can deploy it to Azure.
If you have stateful services running like background threads (which is bad anyways), or if you save data to the file system (besides temporary caching), then you may have issues. Really, the issues moving to Azure are really the same as moving to any multi-server load balanced solution. One caveat is permanent storage.
If you need to store data in a place other than the database, then you're best off working with Azure's storage solution which has an API and client library for storing binary data, key/value data (they call it tables, but really, it's not tables), and queues. They also do have a transparent blob-as-file-system option for compatibility. If you want to use these in your app that also is used outside of Azure then you need to write an extra layer between your code and the Azure client library that supports both Azure services and standard local service. Azure SDK does include emulators for Azure services, but they're definitely not meant for production use.
As far as the mechanics of Azure-specific projects, that is actually not that difficult. Yes, you need to create an Azure-specific project in your solution that defines the Web Role and what gets deployed, but it will reference your existing Web Application, not the other way around. You can deploy the Azure Web Role to Azure or you can continue to deploy the existing application to IIS normally and concurrently.
Web Site, Web Application, MVC, really doesn't make much of a difference. Actually doesn't have to be .NET either. Can be PHP or Java or whatever you want to put on your VM. It'll all work the same as far as Azure is concerned.
MS likes to push Azure as a Platform-as-a-Service (Paas) solution where they have a ton of services they offer and you run apps on their standard platform, and contrasts that with Amazon AWS which they call Infrastructure-as-a-Service (Iaas) which is "just" a Virtual Machine. However, MS is really just as much a IaaS solution as AWS, perhaps even more so. The only difference between AWS and Azure is AWS allows you to choose what to install on your VM and with Azure you have to use Windows Server 2008 R2 as the basis for your VM (but you can customize the VM image to install custom software on top of windows). With both Azure and AWS, the hosts offer additional PaaS services you can take advantage of for data storage and message routing. AWS also offers tons of extra services like video streaming.
Also note that with Azure (and AWS I think) you can use the services they offer even in a non-hosted application. If you want to use Azure's data storage from a non-Azure application, you can do that, it's just HTTP REST calls to get/put data. The only differences you pay for data in/out between datacenter and your non-datacenter-hosted application which would be free if the app was also inside the datacenter (just the data in/out is free in-datacenter, you still have storage and transaction fees).
A few things:
Samuel Neff's answer mentioned mounting a file system in a blob (a Cloud Drive). Only one instance may lock this cloud drive for writing, so it does not behave like a network file share. You'll need to plan for this.
You'll need to integrate with the Windows Azure diagnostics subsystem, to gain visibility into your app's run state (e.g. performance counters, trace logs, etc.).
If there are 3rd-party apps that your web app depends on, you'll need to install these. These actually get installed as part of the role instance's boot process, either via your OnStart() event handler or as a startup task. The latter allows for admin-level installs (including registry changes, COM component installations, etc.). You'll need to carefully manage these installations, as they impact the boot time of the instance.
For an asp.net app, you'll need to think about session state. In-proc session state won't work, because each instance will have its own state store in memory. The SQL Azure session state provider doesn't have background cleanup agents, so you'll need to build this into your web or worker role instance (see this blog post by the SQL Azure team for the implementation). The best option is to use the AppFabric Cache, a new service that just went into production. This cache-as-a-service provides an custom session state provider for asp.net as well. Note: As of today, the AppFabric Cache service is only accessible via a .NET interface; there's no REST interface for it (all other storage services - tables, blobs, queues - have a REST interface). .NET, Java, and PHP all have storage client libraries. Ruby has one from the open source community.
You'll have to manage scaling out to more than one instance, when the need arises. This is not a built-in service today, but there are 3rd-party services such as ParaLeap's AzureWatch. There's also Microsoft's System Center Operations Manager, which now has Windows Azure monitoring support. You'll also need to handle scale-back situations, where you reduce the number of server instances.
I have some additional details in an answer for a similar StackOverflow question, here.
I have not tried Windows Azure Migration Scanner personally, but if it works as advertised, this would really come in handy.
I'm trying to access local file system from Flex web application.
I know it is pretty difficult, but I think there must be a way. Is there a way that Flex app can use AIR components or maybe web application can call some AIR module in order to choose files and upload?
There is no direct way that a web based Flex/Flash application can access AIR based APIs. They aren't built into the Flash Player, but are rather extensions built into the AIR runtime. You can't access them directly because they aren't there.
If you have an AIR app installed on the user's local machine you can, in theory, use that app as a proxy with localConnection. That way the AIR app can access the file system directly, triggered by the browser based app. I'm not sure how user interaction would work, though.
If you have server software installed on the client machine, you can trigger file processing commands from Flex using RmoteObject/HTTPService/WebService commands. This wouldn't give the user any interaction ability and is not usually practical unless you have strong control over your client machines.
Either approach would present an app installation nightmare; which almost defeats the purpose of a browser based app in the first place.
You can use FileReference's methods to ask user to select files to open (load into flash, upload into server) or save (from server or bytes from flash).
This might be a 'duh' question after all.
Are there any caveats running an asp.net (3.5) application on a local host? Assuming I have all the required services installed, I am looking for pitfalls/ troubles in terms of
database access
reporting/ charting and other such features
performance
The main reason for this is that the app I am developing will be eventually hosted on a proper web server but till then I want to be able to use my app from a browser (for test, demos...).
[Note: till the time the app is hosted on a web server, only I will be using the app]
As long as you install all the same components (and the same versions of them to be 100% sure) on your computer as you have available on the server, there shouldn't be any difference at all in functionality. One thing to watch out for is that the app will certainly be less responsive when someone accesses it over the internet, compared to the client and server being the same machine.
You won't have any problems at all, this is how many people indeed test. When you are ready to move it online, just make sure the host supports everything you need.