I think I may be missing something and hope you can advise
I have been developing a project using VS2013 with EF6. I use Visual Studio each time I want to deploy the latest version of the system to my Azure Website.
The Azure Website has a linked database resource (SQL Azure database).
This has been going great. However, yesterday I decided to create a Virtual Machine and move the SQL database to a dedicated Azure Virtual Machine. So I did this and now I have a new database as well as the old linked resource one
So, i'm ready to publish the APP and set the new database settings on the VM.
I changed the connection string in the publish wizard and published being sure to have the right settings, i.e. use this connection string at runtime and execute code first migrations etc
However, it took me a while to realise that the APP on the cloud server I just published too is still pointing to the OLD linked resource Azure database
I'm not sure what else I have to do to, I thought it was only about changing the publish setting for the database connection string
Am I missing something, should I delete the linked resource in the Azure Website settings, if i do would that make it work. Just weird because like I say i'm publishing the site again with new settings, or does Azure read the portals publish settings and somehow overidde what I want it to point to database wise
Please advise, many thanks
John
PS I can connect fine to the new database from my local management studio. I have no errors i'm just not sure how to tell Azure to use the connect string in publish profile other than what i am doing
The "linked resource" in the Windows Azure management portal should have no impact on your application's functionality. It is really just a way to help you understand / visualize the resources your application is using.
Related
We have TFS 2019 installed on premise, want to create PowerBI reports based on analytics Views that are already predefined in TFS. Selecting GetData in PowerBI yields a login screen with collection URL and Team Project. We entered TFS sever name in URL connection and the Team Project respectively, getting an error "invalid account". Prior to this PowerBI asked for Login, logged in with my microsoft user. Can u please advise how to connect Power BI to a TFS on premise, we didn't find helpful material searching for it on the internet. Thanks in advance.
Can u please advise how to connect Power BI to a TFS on premise, we
didn't find helpful material searching for it on the internet.
Assuming you have Power BI Desktop in MachineA. Now you need to make sure:
1.The Azure Devops Server is running and you can login the web portal of Azure Devops Server(once called TFS) in MachineA's browser:
2.The Analytics View option is enabled and you have access to view/edit them:
3.In Power BI Desktop: For on-premise Azure Devops Server, the Collection Url shoule be the team collection url instead of simple ServerName or OrgName:
The Team Project name is one of your project name. For me I have Project ForTest in organization Test. And my full url of the project is: http://xxx/Test/ForTest/. So I enter http://xxx/Test/ for Collection Url and ForTest(simple name of team project !!) for Team Project, then it works well to connect to the server:
Ps: I use Azure Devops Server 2019 Update1(1.1) and latest Power BI Desktop downloaded from Microsoft Store.
Hope my steps make some help for you :)
When the login window appears which asking for Account Name to connect TFS, you need to write only name of the account (beginning name of visualtstudio.com) and write specific project name or * if you want to get data for all existing projects.
Eventually what worked was full URL of the collection in the first field and name of team proejct in the second field.
I am trying to see how the OpsHub migration tool works before I perform real migration.
And hence I am trying with a on premise TFS instance and a trial created Team Services (was Visual Studio Online) instance. but when I finish configuring the stuff and it start to validate all the settings put in, it is giving error for Team Services Project Collection URL. It is taking collection URL as
https://********.visualstudio.com/********
where as it should only use
https://********.visualstudio.com/
Not sure how to get over it and now fully stuck.
This is caused by the change in VSTS:
Collection in the domain
Your Team Services account URL just got 18 characters shorter. We’ve
removed “/DefaultCollection” from the path. While it’s small, but
welcome change. It’s the beginning of a larger journey to how we
structure accounts. Learn more here.
Note that existing accounts will still give out the longer URL for Git
Clones in the Code hub. This is because to use the new shorter URL in
VS, you will need to reconnect Team Explorer using the shorter URL.
Today you either need to use the long or the short URL for an account
in VS, you can’t intermingle. Once we have enough clients updated such
that they just work seamlessly with either type, we’ll change the
default Git Clone URL to the shorter one as well.
Last but not least, we have a set of Release Management improvements.
Please download the latest version of OpsHub Visual Studio Migration Utility and then try again.
A similar issue here: OPS Hub - unable to migrate project.
I've spent the past few months developing a webApi solution that I'm ready to push up to Azure and hook into an Azure SQL Database. It was built with EF Code First.
I'm wondering what standard approaches there are to making changes to the database while in production. I've been using database initializers up to this point but they all blow away data and re-seed.
I have a feeling this question is too broad for a concise answer, so I'd like to ask: what terminology / processes / resources should a developer look into when designing a continuous integration workflow for a solution built with EF Code First and ASP.NET WebAPI, hosted as an Azure Service and hooked up to Azure SQL?
On the subject of database migration, there was an interesting article on ASP.NET about this subject: Strategies for Database Development and Deployment.
Also since you are using EF Code First you will be able to use Code First Migrations here for database changes. This will allow you to better manage the changes you make to the database.
I'm not sure how far you want to go with continuous integration but since you are using Azure it might be worth it to have a look at Continuous delivery to Windows Azure by using Team Foundation Service. Although it relies on TFS in the cloud it's of course also possible to configure it with for example Jenkins. However this does require a bit more work.
I use this technic:
1- Create a clone database for your development environment if it doesn't exist.
2- Make the necessary changes in your dev environment and dev
database.
3- Deploy to your staging environment.
4- If you added some static datas
that should also exist in your prod database, use a tool like
SQLDataExaminer to find the data differences and execute the
insert, update, deletes for according rows. Use Schema Compare in VS2012 to find differences between your dev
and prod environment by selecting source as dev and target as prod.
And execute the script in your prod.
5- Swap the environments
I am running a mobile service with an increasing amount of scripted functionality. I want to have these scripts somehow stored in a smart format for version control. I'm having hard time finding any information on such scenarios. Is it even possible Azure -> VS2012 (and TFS) or VS2012 (and TFS) -> Azure?
Currently that is not supported on the portal itself. You can do that by using the Command Line Interface, however, as was shown in this blog post. Basically, you can store the scripts in whichever source control system you want (the post uses Git, but it would work with TFS as well) and use the CLI to update your service whenever a new version of the script is checked in.
You can also vote up the source control feature suggestion on the UserVoice for the system, to have that functionality implemented in the service itself.
You can now link your Azure Mobile scripts to a git repo directly from the Azure Mobile Portal Dashboard, allowing you to edit scripts from VS2012 or another editor.
I develop on my local machine with VS2010 and SQL Server. Naturally, my web.config points to my local SQL Server and I can debug/development and all is well. Unfortunately, I am not entirely sure on how to go about deploying my code to a live server.
Currently, my live server consists of a virtual machine (my site is accessible from the internet). When I'm ready to put my changes on the live server I publish my app (right click on solution explorer -> publish). Then I go to the directory it publishes to and dump all the files into a network share that goes to my site on the live server. On the initial copy over, I have to manually edit the web.config so that the connection string points to the SQL Server on the live server instead of my local machine. So this is my first stumbling block. How can I easily manage development settings and "live" settings in the web.config?
Now, I also use version control (Kiln). Can I possibly tag a changeset and have it automatically deployed to my live server somehow? Let's say someone submits a bug and I fix it. I push my changeset and now Kiln has the latest version of my code with the bug fix. What's the best way to get these changes on to a live server?
I'm unable to find any documentation that covers the entire workflow but I feel like there has go to be a better way. Surely, something like this can be accomplished without having to manually edit the web.config everytime I publish and pray to the computer Gods that I didn't miss something in the connection string.
It's just me so I have complete control over all of my environments, including the server and what's accessible via the internet, and anything is possible if only I knew what to do.
How can I easily manage development settings and "live" settings in the web.config?
Re: With VS 2010 web.config transformations, it is quite easy. Please take a look at this blog:
http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
For VS 2008 or older, we used to have multiple config file based on environment and we used to create Debug/Release/DevTest/UAT/PROD release configuration and then in the post build event we used to replace the web.config with the release configuration based config. For example - if you build the project using "Prod" release configuration then we copy the PROD web.config to the publishing folder.
Now, I also use version control (Kiln).
Can I possibly tag a changeset and have it automatically deployed to my live server somehow? Let's say someone submits a bug and I fix it. I push my changeset and now Kiln has the latest version of my code with the bug fix. What's the best way to get these changes on to a live server?
Re: Source control and publishing to live server are two different things. The first question you are asking here related to how you manage multiple releases and have control over bug fixes for each release. The way I would do it is I will have PROD branch in my source control which will be the first release and for every major release I will sub branch it to have more control over e-fixes.
For the other question about how to get it to live server, it depends on your environment. We do it differently based on how customer environment is setup. If they have given us the FTP, we use that or otherwise we package the application into an MSI and then deploy it to UAT.. Until UAT signoff is done, we keep on updating the MSI. Once signoff received, the MSI goes to PROD.
Hope this helps.