Develop Reference

Backup database with Entity Framework on ASP.Net

I have an interesting case. I lost access to an Azure subscription. However, I still have access to publishing an ASP.Net application, because I configured a publishing profile, which still works. Note, that this is nothing illegal - internal company policies regarding VS subscriptions; enough to say, that application is mine, written by me, maintained by me etc.
I need to create a backup of the database, but the only thing I can do is to publish the application. Application obviously have connection string embedded in settings, but I cannot connect to the database due to firewall settings (Azure services only). So I need to find a way to dump the data with a controller and action.
So far I managed to dump most tables manually (eg. var data = context.Table.ToList();) and then output results into view. However, this won't export internal ASP.Net tables, which I cannot access directly (eg. user/role claims etc.)
Keep in mind, that we're talking about Azure SQL, which differs from the regular SQL Server.
How can I back up the database, so that I can migrate application to a different subscription?

If you also can publish your webapp. You can create a API function and invoke it. Something like: https://yourwebsite.azurewebsites.net/backup/start.
You can create PROCEDURE, and run it to generate .bak file to blob（
The premise is that you need to know blob related information.）.
Sample code like :
C# SQL Server backup of a remote database to the remote default backup location without direct access to the remote location?

Azure cannot connect to SQL Server

I am an Azure newcomer.
I went through
Get Started with Azure Cloud Services tutorial and can run the Contoso Ad app locally.
When I push it to my dev/test Azure account, the app cannot see the database.
You can see it live here: My Dev/Test Azure instance running Contoso Ad App
I can run SSMS locally and connect to my database:
(this works fine)
I did have to add my home IP Address to the Firewall rules:
Questions:
Is there any way I can see more about what Azure doesn't like when trying to connect to the database?
I followed the tutorial step-by-step, and I'm sure my connection Strings are correct, especially since I can connect from SSMS at home. Any firewall changes that need to be made so an Azure Web App can see an Azure SQL Server database?
Thank you very much in advance!

This turned out to be me not fully understanding how
Web.Config
Web.Debug.Config
Web.Release.Config
interact.
I learned that Web.Release.Config is only modifying upon a Web/Azure Publish, so I did not see the changes reflected in the local <project>\bin\Release folder.
I also learned that by changing the Connection String name in Web.Release.Config, this caused it to not match and transform/overwrite the value in Web.Config.

Publish web-site vs Azure Cloud service publish

There are 2 ways for publish website to Azure - via simple Publish feature vs Deploy as Cloud service. I have also one worker role in solution, so, I selected Cloud Service instead of simple Publish website feature.
But I'm very disappointed with Cloud service. First at all, deploy as cloud service takes in 10 times more time, than simple Publish website. Second problem - I have to each time, when I want to deploy, change connection strings in web.config to SQL Azure (instead of my local SQL Server). Website Publish has ability to set necessary SQL connection strings for deploy. Maybe I do something wrong and deploy can doing in 10 sec and exist ability to set different connection strings (like Website publish)?
I think about put to Cloud only worker role and website deploy as website, without Cloud service...

First, I would highly recommend that you go through this question comparing Azure Websites and Cloud Service: What is the difference between an Azure Web Site and an Azure Web Role
Now coming on to your questions:
First at all, deploy as cloud service takes in 10 times more time,
than simple Publish website.
It is bound to happen because when you deploy a cloud service (say through Visual Studio), following things happen that will cause the delay:
As a part of build process for cloud services, Visual Studio creates a package file and uploads it into blob storage. This package is then used to create a cloud service.
Azure Fabric Controller which is responsible for managing life cycle of a cloud service creates a brand new Virtual Machine for you, installs necessary software (IIS for example) and then deploys your code from the package file.
Both of these things don't happen in websites.
Second problem - I have to each time, when I want to deploy, change
connection strings in web.config to SQL Azure (instead of my local SQL
Server). Website Publish has ability to set necessary SQL connection
strings for deploy. Maybe I do something wrong and deploy can doing in
10 sec and exist ability to set different connection strings (like
Website publish)?
You're not doing anything wrong per se. Your web.config file gets bundled into the package file so after any change you make to your web.config file, you would need to recreate the package and update the deployment (which will include uploading to blob storage).
One possible solution for your problem would be to use config transformation and have your web.config.release file contain the connection string for your production database. When you build your project in release mode, you will have correct connection string in your web.config file.
I think about put to Cloud only worker role and website deploy as
website, without Cloud service...
This is certainly a viable option. Another alternative would be look into WebJobs. Like Worker Roles, they are meant for handling background processing workloads but have the same convenience of a website when it comes to deployment. You may also find this blog post useful as well: http://www.hanselman.com/blog/IntroducingWindowsAzureWebJobs.aspx.

WCF Service Problems

I'm having trouble setting up my WCF Service to an IIS server. The current setup I have is a WCF service written in C# that accesses an external database (located on a different server, different location than our IIS server) and an ASP.NET web site that consumes the service on our server, and uses it's methods to query, then display some data.
Before I uploaded the Service and website to our server, I tested it using the default setup done by Visual Studio. This test led to promising results, because when I let visual studio host the service (and whatever else it does in order to setup the environment for testing) and consume it with the website, everything went smoothly, and all of my queries went through flawlessly.
I can upload the service fine, consume it fine with the website, but I have problems when my service makes queries to the external database. I get an "underlying provider failed on open" error when an actual query is made. I've tried a few different things and I couldn't find an answer. For legal reasons , I'm not allowed to upload the code, but I think this problem is due to incorrect setup on the server.

Assuming that you're using Entity Framework, that problem almost always indicates that there is an issue establishing a connection to your database. Check your connection string and make sure that the server and instance names are correct, and that the user your service is running under has access to the database. If you're hosting in IIS, this would usually be a service account (e.g. NETWORK SERVICE) or local system account.

The issue ended up being the connection string in the end. On my local machine, the name of the server was resolved with the Hosts file, but the server had nowhere to resolve the name of the server mentioned in the connection string. This was causing the issue. This has been resolved by updating the server hosts file.

I've gotten this error on new installations of SQL Server, and I fixed it by enabling Named Pipes in SQL Server Configuration Manager. Could be the same issue you're having.

What is the recommended approach for deploying to multiple Azure environments (dev, test, production)?

I have an C# web application using mvc5. It currently runs on Azure and I have a dev, test, and production instances. What do I need to do to ensure that the database connection strings will automatically change as the application is pushed to each environment? I know this is possible with web.config as you can define Web.Debug.Config, etc, but how would I go about this for different worker roles on Azure? I have been all over the internet looking for a solution. In a nutshell, I would like to do the same approach used for the multiple web.config files but for Azure.
As some additional background, for my solution I have my repositorybase broken out into a separate project and there I am trying to grab the connection string from the configuration files (let's say domain.dll is the name of the library that contains it). As first this worked when I was only using web.config but when I had to run my domain DLL files from another worker role the configuration began to return null; because this code would not run when run from a different worker process(non web). This seems to introduce an interesting problem, what if I need to use the domain.dll code outside the web and outside of Azure? How do I still maintain the connection string benefits that Azure and web.config provide?

Assumption: you are using Web-Services, not Web-Sites. There is a difference.
There are 2 ways to get what you need:
For worker role you can do app.config transformations almost in the same way you do in web.config. Only you'll need to do it with SlowCheetah. There is a nuget package for that, also there is VS extension to create transform files. There is too much faffing-about with this method. I never liked it, so move on to second option.
If you run Web-Services, you can specify connection strings as part of worker-role configuration. Go to your Azure project and open properties of your worker-role:
There you can add database connection string. And create a configuration for every environment you run (dev, test, prod). And place a different connection string for every environment.
To get your connection string you execute:
CloudConfigurationManager.GetSetting("DatabaseConnectionString")
Once your site is deployed you'll see these configuration values in Configure tab in Azure Portal.

You should make the distinction between 'building in release mode' and 'deploying to environment X'.
Building in Release mode should just transform your configuration files to be 'production-ready'. With MsDeploy you can parameterize your configuration files so upon deployment they will be filled with the parameters as supplied by you to your MsDeploy script.
There is no magic bullet which will automatically change your connectionstrings etc per environment. But this way you can standardize your process which will greatly help with the stability of your product.
One thing to note is that the parameterization of your deployments will break the easy workflow 'publish' from within visual studio due to the fact that you are not given an option to fill in your parameters during the publish wizard... :'(

You should manage the connection strings through the azure portal rather than through config file transformations. With the MVC app this will be easy, go to the configure tab and set your connection strings there
For items like web jobs use Microsoft.WindowsAzure.ConfigurationManager which
provides a unified API to load configuration settings regardless of
where the application is hosted - whether on-premises or in a Cloud
Service