I have a Web application which will be deployed to Windows Azure and I'm looking for alternatives to generate Excel spreadsheets.
Can I use VSTO to programatically generate an Excel spreadsheet in a Web Role running on Windows Azure?... If yes, how should I deploy the application to Windows Azure? What assemblies should I include?
Joni and Joe are correct. VSTO will not run on Azure.
I believe you're looking for the Open XML SDK. That lets you create Excel or other Office files from .NET without using Office automation.
Edit: Here's one option I have considered for those times when the Open XML SDK just doesn't have the functionality I can get from accessing an Office app's object model directly. Set up a machine outside of Azure that operates just as an Azure worker role would by processing messages from an Azure Queue. Since the app on that machine could be setup to execute tasks sequentially, you should be able to get away with things that wouldn't be advisable if you were trying to execute an Office app from a web role. This machine could be in your data center, or you could use an Azure VM so that you could install Office. If that VM was creating and/or reading Excel documents, then just use Azure Blob storage to store the documents.
If the machine running Office is outside of Azure, you will incur additional bandwidth costs for all the data coming in and out of Azure.
I tested this and apparently it won't work, VSTO requires Office to be installed.
I've been successful with generating Excel Spreadsheets in Azure using EPPlus open source project. It builds on the OpenXML SDK, but is much simpler to use.
I've been deploying the code to Worker Role instead of Web Role (as per Lokad.CQRS for Azure architecture) in order to pregenerate reports, so that the application would be more scalable. And the only required assembly was the Epplus.dll.
Related
I have created an office add-in within visual studio code, I have published it on my Azure Storage Account, and via Centralyzed Deployment I've managed to install it for some users. The problem is that this add-in must be used by some clients, and there is no possibility that they'll use the addin stored in my azure account, and there is no possibility that they will create an account for me on their organization, in order for me to push data directly on their organization's azure account.
So what are the options? I need a solution where i send the office add-in as a zip or something like that, and the company's admin can easily upload that to its Azure account, and the manifest will point to their location. I've seen the possibility of downloading the addin from azure via ftp (without success yet), I imagine if i download that, there might be an option to upload for the client's company admin. Or am I on a wrong track?
many thanks!
I have a Win32 application written in VB6 that uses an MS Access database as its data file.
I have about 30 clients who use this application. Each currently has it setup in their local network. Some clients have a Terminal Server for staff to access their network remotely.
A number of my clients are inquiring about the possibility of using the application in the cloud.
I am considering the possibility of ultimately making the application web based in some form, however that will take many months to do. So, in the meantime, I am looking for suggestions as to how clients could run this application in the "cloud".
Would it be possible to run it using Microsoft Azure in some way?
I am also wondering whether I could rent a Virtual Private Server myself, and then set it up to allow multiple clients to connect to it (with each using their own individual data file). My main question around this option is whether there would be additional license costs for users who need to connect (eg. like the old Terminal Services "Client Access Licenses").
One function of the application is that users are able to "attach" electronic files (word documents, pdf's etc) to file notes. These "attachments" are stored in a subfolder of the data file location (ie they are not stored in the data file). So the solution must be able to support uploading local documents to the "cloud" service.
Any ideas would be most welcome.
Many thanks,
Rohan
You could try it with "Virtual Machine" feature of MS Azure.
Acces portal.azure.com
In the left navigation bar, choose "Virtual Machine"
Click "Add", type "windows" into the search field & press
Enter
Choose the Windows VM you want
Connect, upload your VB6 app & test it...
Please be inform that some Windows VMs require MSDN subscription or cost very much.
The Azure feature you are looking for is likely Azure RemoteApp. It allows for desktop applications to be installed in the Azure "cloud" and then used by users from any device using Remote Desktop Services functionality. This way you can control the environment where the application is installed, and not have to configure every users device; which is especially helpful with older legacy applications like VB6 apps.
https://www.remoteapp.windowsazure.com/en/
EDIT: Unfortunately on August 12, 2016 Microsoft announced they are discontinuing Azure Remote App. New purchases of RemoteApp will be discontinued October 1, 2016, and the service will be replaced with an offering from Citrix called Citrix XenApp Express.
I think you should simply create a virtual server for each of your clients. Do not create 1 virtual server for everyone, that will be a nightmare and very insecure for client data.
The clients would still just access over terminal services or Remote Desktop as they have before, just the server is now in the cloud.
Then you can bill each client for the what you are charged for their server.
RUN EXCEL/ACCESS DATABASE ON THE CLOUD WITHOUT PROGRAMMING!
I can solve your problem without using Azure or similar. We would first convert your Excel/Access database to a Progen4GL-based applications, which will then run on the cloud. See downloads on www.progencloud.com.
If you can, send us a similar Access/Excel file. We will convert it to a Progen4GL database that you can run the on the cloud with full read/write access. As Progen4GL reads in Access/Excel files without programming, we can do it for your for nothing. It takes only a few minutes for the to conversion to a Progen4GL Database. We will return it to you as a Cloud application. See Progen DataOWL on www.progencloud.com and try it yourself. You will need some help from us to run it on the Cloud as the website doesn't have full details.
Ravi Raizada raviraiz#aol.com
www.progencloud.com
Is there any ability to install a "development environment" for Azure, or a local equivalent that supplies all the same APIs, storage methods etc?
The end game is to not pay for Azure while I'm developing.
Yes, Azure SDK and Tools come with a local emulation environment that closely resembles real Azure and allows one to do most of development without ever deploying a single bit to Azure.
Emulation is provided for Roles and Azure Storage (Tables, Blobs, Queues).
If you need SQL Azure, suggestion is to use regular SQL Server and closely stick to compatible functionality only.
Just go to the Windows Azure page to download the SDK and tools - the installation is streamlined using the Web Platform Installer.
The local simulation environment simulates blobs, tables, and queues, as well as compute instances (although as separate processes, not as separate VM instances). The APIs all work in the local simulation environment.
To use SQL Azure, you'd need a real account. Same thing for the AppFabric services.
Just so you know: you can get a completely free account for 30 days, with SQL Azure, AppFabric services, and a few compute instances. Go to www.windowsazurepass.com, and use promo code DPWE01.
EDIT: Agreed with Igor in his answer: you can develop with SQL Server and then push your database up to SQL Azure. The latest SQL Server Management Studio supports SQL Azure-compatible sql output scripts. As Igor points out, just stick to compatible SQL (which is a very large subset of SQL Server).
The SDK is the way to go, but note, deploying worker role instances can be quite a bit more complicated, but testing locally once the SDK is installed, is fairly straight forward.
What type of projects/software applications are suitable for Azure and why?
Thanks
Rather than thinking of what can be supported in Azure, it might be more helpful to think about its challenges as you decide to port your app over:
Web applications. Since a Web Role hosts IIS, you'll generally have little issue porting a general-purpose asp.net or asp.net mvc website to Azure. There are some glitches you'll run into - see my related answer for more details.
UI. If your app has specific output similar to a WinForms app, you won't be able to run it since you have no video output.
GPU dependencies. If you're doing some background processing dependenton a specific GPU, you won't be able to run in an Azure VM.
Registry and other system-level access. If your app needs to update the registry or run an MSI, you won't be able to install your app.
Instance affinity. If your app requires session stickiness (e.g. a logged-in user MUST visit the same server instance with each access), you won't be able to accomplish this.
COM interop. COM interop is very limited, since you can't install anything via the registry. If you rely on Excel Services, you won't have that capability.
SQL limitations. SQL Azure is limited to 50GB today, and offers no ability to custom-tune the server instance. Also, while it does support a big subset of SQL Server, it doesn't support 100% of SQL Server, so it's possible some of your sprocs may no longer work. There's no SQL Agent today, so you'd need to recreate that functionality in a worker process.
That's just a quick braindump of some challenges you might run into - I'm sure there are others.
Just keep in mind that Azure is providing Windows 2008 Server images for your app to run on, so if your app can run in that environment today, and doesn't require things I listed, you should be in pretty good shape.
You can make most of the .NET projects working in Azure. Azure has support of following project types: web site (both ASP.NET and ASP.NET MVC), worker (background application) and wcf service.
Don't forget security too - there's various ways of authenticating onto Azure but none are as simple as just setting IIS/ASP to windows auth.
Following the release of SharePoint 2010, there has been renewed interest in using PowerShell to manage SharePoint solutions. I'm interested in finding out how my peers are currently using PowerShell with SharePoint, either 2007 or 2010.
For example, I use a PowerShell script to determine the number of sites, sub-sites and pages that have been created in specific web applications. Can you provide details of how you make use of PowerShell?
We're developing some custom SP2010 software. We're using Powershell cmdlets to install and upgrade builds on our test machines, as well as do some initial configuration tasks such as deploying features to certain webs, and creating service apps & service app proxies.
Unfortunately the cmdlets don't seem to play well with PSRemoting, which makes automated build & deploy trickier.
I use PowerShell for installation and debugging purposes. I'm surprised that you haven't used Powershell with SharePoint 2010.
I write quite a few scripts for deploying and managing many solutions. For Example, Every time we deploy our PerformancePoint dashboards, it removes the top the global navigation. I use a Powershell script to re-insert the global navigation based on a XML File that I have created.