I've added a setting to ServiceConfiguration.cscfg with the idea that it will allow me to turn on/off a feature of the MVC app. The code correctly reads the setting however while running the app in local dev compute emulator, I don't see the ServiceConfiguration.cscfg file in the .csx directory. I only see the ServiceDefinition.csdef file which has the key but not the value. I want to change the value.
The idea is that I have a text file I can alter after deploying that will allow me to turn on/off parts of the app by opening text file on Azure and making changes.
I don't want to be dependent on Azure Storage or a hop off the Azure box.
What is the best way to change my own app config setting in azure?
Well,
Your path is correct. ServiceConfiguration.cscfg is one of the places where you could have service wide settings. And there is one gotcha here, you can't dynamically change the service configuration with local Azure emulator. If you want to change something in the service configuration, you have to stop your debugging session, change the setting and start new session. Only in live Azure Environment, you can change the service configuration, and it will be propageted to all instances.
I intentionally bolded service wide settings. With full IIS mode (available since SDK 1.3) you can have multiple web sites per single Web Role. That would mean multuple applications. Now I would not want to mess setting for one of the applications, with settings for the other. That is why I would put an application wide settings in an Azure Table. And your application may query this table every N seconds/minutes, depends what is your targeted response time.
I wonder what are your thought begind the "I don't want to be dependend on Azure Storage" statement? Before all, you are developing application for the Windows Azure platform. Ain't you going to have any dynamic data? File uploads or file generation or anything like that? Check out the Windows Azure Storage SLA. I don't think a Windows Azure storage (in your case I suggest Tables) would be in any harm for your application. Especially when your service deployment is in the same geographic region as your storage account.
Related
I have a Teams application (Tab). I am an ISV provider, and provide a multi-tenant application that is installed by customers via Teams App Store in their organizations.
How do I save settings for my application organization-wide for the customers? For example, CustomerA has installed the app and then CustomerB. I want some storage that would be unique for CustomerA and CustomerB and the app, and located in customer's environment. The settings I want to save are not per-user, but per-organization (tenant).
Somewhat similar to "App Data" folder you have in Windows Desktop for example.
Does such a storage exist? Does API for this storage exist?
A tab app is a simply a web application that you render inside of Teams. As a result, what the app does, and where and how it does it, is totally up to you. This includes any data storage you choose to have behind the scenes. For example, your tab could be built in PHP and use MySQL, or built in ASP.Net and use SQL Azure or CosmosDB. It's totally up to you, but you need to implement it yourself, as an ISV.
The important piece to differentiate clients, however, is being aware of the TenantId for each user, so you can look up which client's settings you need from the database. The most simple way to do this is simply the tid property on the Teams tab context. You can read more about that here. Unfortunately, because it's just accessed via Javascript, it's not entirely secure - for a more secure mechanism, you should be creating an Azure Application, and generating jwt tokens that you can authenticate against in your backend. It's a much more complex topic, but hopefully this answer at least gives the background you need. For more info on the security aspects (validating the token etc.), please see this question: How to restrict access to Azure Function to only allow requests from a custom Microsoft Teams App?.
What is the best way of storing/loading developer specific application configuration settings in asp.net core. The support it provides for Dev/Staging/Production is great but...
It looks that you need user secrets.
Sensitive values are stored in 'separate' place on machine, and app during startup add this values to other settings.
I'm researching some Windows Azure stuff, in order to make a decision whether to move to Azure or not.
Basic information
To answer the question, you'll need some basic understanding of my app so here goes.
The app is an ASP.NET MVC 3 application that connects to a SQL Server database.
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server, deployed to IIS 7 as a website.
I have one SQL Server, where each instance has its own database.
I also have a set of Windows Services to do some background processing. That should be straight forward, as I'll just rewrite those to use a Worker Role in Windows Azure - most of the logic in the services is located in their own class (library) anyway, so the service it self just calls one or more methods in a class.
Now to the question
Whenever someone signs up for a free trial, I add a record to an Admin database I have.
I then have a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders, runs the database deployment script and updates the record to reflect that it has now been deployed, and finally sends an e-mail to the prospect that their free trial has been created - here's how you access it.
So, how can I deploy a new instance in Windows Azure from a Worker Role? Preferably, I'd just add a new website to an existing Azure instance and create a new SQL Azure database for that particular site to use.
Does this require a lot of work to set up? Is it even possible?
Based on two quotes, I would like to suggest calling this a multi-tenant application:
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server,
And...
a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders
If I understand correctly, there is "one" IIS server (well, in Windows Azure, it's one Web Role, scalable to multiple instances), and with each new "tenant", you set up some new stuff to support that tenant.
If that's indeed the case, you can definitely do this from a worker role - just look at Nate Totten's multi-tenant web role blog post and related code. Look at the webdeploy code that actually manipulates IIS.
Further: take a look at Cloud Ninja, a project a few of my teammates published along with Fullscale180. This is a multi-tenant app that demonstrates how to manage multiple customers in a single deployment, as well as monitoring and scaling.
Finally: should you need to actually create brand new service hosts and storage accounts, the latest updates to the Windows Azure Management API support this.
I hope that helps a bit...
I think most of the things you want to achieve are possible.
It will definitely require some work to setup!
For some ideas on how to achieve what you are looking for, take a look at the MS SaaS example - http://www.fabrikamshipping.com/ - especially designed for porting existing apps to SaaS on Azure. Inside this app they have an "onboarding process" - and that process includes setting up new SQL connections and new portals.
There's lots of good blogging (watch the video) about this on http://blogs.msdn.com/b/vbertocci/archive/2010/10/07/new-online-demo-introducing-fabrikamshipping-saas.aspx
I heard that apps don’t port directly and they have to be specifically written to work with Azure. I’m new to Azure and did some reading but I don’t see anything from their site or documentation that suggests that you must specifically code for Azure, so is it true?
If this question is better suited for another StackExchange site please let me know.
You should take a look at the Windows Azure Platform Training Kit to see some introductory project labs.
While you theoretically can just "drop in" some apps into a Windows Azure VM, it hardly makes sense to do so. Some apps can be migrated with only minor changes, such as an asp.net website - session state is easily handled by AppFabric Cache, and the Web Role VM is Windows Server 2008 with Full IIS. However, you'd still need to integrate with Windows Azure Diagnostics, to be able to have external visibility to the health of your app.
Further, with the example above, there are more optimal things you can do, such as moving static content to blob storage, and taking load off your VMs. This requires you to upload this content, and then change your IMG and other tag URLs to point to a slightly-different URL.
Just remember that you're moving to Windows Azure to take advantage of its platform and related services, not just to be a rack to host a server. To take advantages of these services, you're going to have to target them specifically, such as:
Access control services
Caching
Connectivity (vpn, service bus)
Diagnostics
Database (SQL Azure)
Synchronization services
Traffic management across data centers
This is somewhat true. Your apps will typically run as-is. You just need to add an azure project to the solution, and add your MVC apps as roles to the Azure Project.
I found O'Reilly's "Programming Windows Azure" to be a good conceptual introduction to Azure.
We are looking at a standard way of configuring the various "endpoints" of our application. Our application is a distributed system with Windows Desktop applications, Windows Server "services" and databases.
We currently configure each piece using XML files. This is getting a little out of hands as we work with larger customers who can have dozens of Servers running our application and hundreds of desktop clients.
Can anyone recommend a Microsoft technology or a third party that would allow us to centralize all that configuration information and manage it in a one place for all our applications? Any changes would be "pushed" to the endpoint(s) that are interested.
For example, if we were to change the login for one of our database, we would make that change on the database, then reflect that change in our centralized system. Following that last step, any service that needs to connect to the database would be notified of the change (and potentially receive the new data). How and what each endpoint does with that information is outside the scope of the system.
Our primary business is not "Centralized Configuration Services". We are a GIS company that provides solutions for various utilities worldwide.
I've done a couple of things to give myself this functionality over the years. I build enterprise applicatons that may be distributed across many servers. I don't want to bury config settings in each services config file or each web server's web.config file. For application specific stuff I usually create an application settings table in the app's database. The table only has two fields. SettingName and SettingValue. I then write a web or wcf service whose sole function it is to retrieve these settings. I write a function called GetSetting where you pass "SettingName" and it returns SettingValue or an empty string if your setting is not found. This way I can store all application settings for all components of the application in one spot. Maintenance and troubleshooting for this is really easy, I'm not hunting through scads of config files spread across a dozen web and app servers.
For larger scale apps I might create a separate AppSettings database where I add a new field to my table mentioned above. ApplicationName. My web or wcf service for this approach has the same method call (GetSetting) only at this scope I pass ApplicationName and SettingName and it returns SettingValue or an empty string.
Doing either of these things allows you to centralize all app settings for any size application or IT shop. It has worked really well for us.
You could use RSS together with BitTorrent to distribute changes. See Wikipedia. It is not MS specific however, but should provide the flexibility you need - a configuration server holding the configuration and providing the feeds needed to configure the clients and possibly servers.
Any VCS through a secure channel?
For example, git through ssh (both available in cygwin).
I think the first step is to have the secure channel (if you want the push ability, pulling might be different).
As for managing the "versions" in different "branches", what's better than a version control system?
As it goes for the Microsoft requirement, well the Microsoft sofwares in that exists in that area would suck pretty bad in your case (as in not the best tool for the job).