I'm trying to find a solution to prevent my developpers team running the solution configuration "release" which contains the production settings.
I just want to prevent careless error like "OMG, I was in Release configuration during my test, I delete all the database" or something like this...
We are working on Visual Studio 2010 with TFS. I was wondering if there is a right to use a specific type of solution configuration and not an other...
If you know an other way to be sure this kind of error will never append, I'll take it too! ^^
Thanks in advance
As John suggested, you should limit access to your production database first. Next, you could have your release configuration error out if a particular environment variable isn't defined. Just check for that environment variable before you zap the database.
Related
Currently I'm using Visual Studio 2012 RC and SQL Server 2012 RTM.
I'd like to know how to re-deploy/re-create a test database for each test run.
Keep in mind I've a SQL Server database project for the database using Visual Studio 2012's template.
Actually I'm not very sure about an idea I got in my mind, but .testsettings file has Setup and cleanup scripts. Is this the way to go? For example, a PowerShell script reading the database project generated script and executing it against the database?
I guess there're better ways of doing that and it should be an out-of-the-box solution but I ignore it and Google doesn't help me in finding the right solution.
As mentioned you'll probably want to use the VS 2012 .Local.testsettings > Setup and Cleanup scripts to create / tear down you SQL Server database.
For the script you may want to use powershell with a .dacpac (rather than just a T-SQL script), since you are using a SSDT project. Here's a link to some example code - in particular you may want to take a look at the 'Deploy-Dac' command.
If you are unfamiliar with .dacpacs as the (build) output of SSDT-created database projects, take a look at this reference link.
Edit: Although this doesn't answer the question in a plain SQL Server way, an easy Entity Framework approach would be the following: I found that I could create and destroy my database every time correctly by using the DbContext.Database.CreateIfNotExists() and DbContext.Database.Delete() methods in my setup and cleanup phases of my tests.
The fastest solution, while a bit of a hack, is really straightforward. You can set the DB Projects properties under the debugging tab to "always re-created DB". Then test in two clicks, do a debug/build, then run all tests. You should get a freshly built DB on localDB for you tests to be ran against. You can also change the target for the debugging DB (again the DB projects properties) to whatever you want, so you can deploy to a .dacpac, or to an existing SQL DB or wherever. It means testing in two steps, and if your build is long, it may be annoying, but it works. Otherwise, I believe scripting is your only option.
When I run a Windows Azure web role on my local developer fabric, I get the following error:
The current service model is out of sync. Make sure both the service configuration and definition files are valid.
One of my colleagues hit this issue and after a bit of playing about, the problem was that the two service configuration files (cloud and local) had a different number of Settings.
When he updated the configuration files so that they were in sync it all worked.
A tip would be to use the GUI in Visual Studio to add new settings to both at the same time. The GUI can be accessed by right clicking the web role and selection properties. This should open up a window. Click the Settings tab on the left.
For me, this was caused by my azure project having been copied from one PC to another (going from Win 7 to Win 8.1 in the process). I am using VS 2013 Community edition on both, but I had upgraded from Azure 2.4 on Win7 to Azure 2.5 on the Win 8.1 machine.
If you unload the azure project and edit the csproj file, you just need to make a small edit (e.g. adding a comment) and save it, so it re-writes itself. This fixed it in my case (where I'd spent ages checking for errors in the CSDEF and CSCFG files). Once I re-saved the csproj file, it worked fine.
This happened to me because one of my cloud configuration files (.cscfg) was missing some key-value pairs that were defined in ServiceDefinition.csdef.
Going over the files manually was a pain. There's an easy way to discover the descrepancies:
In the Solution Explorer, right-click one of the Roles that make up
your Cloud Service and click 'Properties' in the context menu.
The Role properties window will open up grey with an error message saying:
"Invalid Service Definition or service configuration. Please see the
Error List for more details".
Open the Error List window and in some cases you
should be able to see a list of the specific discrepancies, complete with file
and property names.
I followed all the answers here and it still didn't work
eventually I restarted Visual Studio and it worked.
I believe the solution was the combination of one or more of the answers here + restarting VS.
What worked for me was to:
Make sure the Cloud Services .cscfg and .Local.cscfg files were identical (unless you need your Local.cscfg to have some differences for debugging purposes),
Make sure the .csdef file had definitions that matched the .cscfg files, and then
Close the project and delete its Cloud Services .ccproj.user file.
After reloading the project, all was well.
The error can occour when there is no actual fault in the service configurations.
If it occours and everything seems to be correct, instead of restarting visual studio, simply unload the azurecloud project (rightclick: unload proecjt
Please cross check your ServiceConfiguration.Cloud.cscfg and ServiceConfiguration.Local.cscfg files. My problem was, I added a configuration to Local.cscfg but forgot to add the same to Cloud.cscfg
Had this issue - no errors though. I have found that for some bizarre reason the if the setting:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
was commented out, then the workerrole would not launch.
For me, the issue turned out to be an inconsistency between the vmName value I had assigned to one of my roles in my various environments. I have a *.cscfg files for my development, test, and production environments. Each of these had a role definition that was supposed to be along the lines of
<Role name="HardWorker" vmName="SomeName">...</Role>
but one had an entry like
<Role name="HardWorker" vmName="SomeOtherName">...</Role>
and that, apparently, was enough to trigger the error.
My problem was incorrect certificate definition in csdef file.
For me the problem was that the Wifi I was using blocked the PORT Azure is using, changing Wifi solved that problem.
Do I have to manually edit the Azure connection strings myself to switch between production and development, or is there something comparable to the Transformation Visual Studio applies to Web.Config?
To add to what Brent has said. I use a special small configuration-only (Config) project that contains a folder for every deployment type - inside each folder there is a collection of .config and .cscfg files that are tailored toward a specific deployment (a few partial .config files too). During every compile via Pre-Build event step, Visual Studio copies the files from the correct folder into the root folder of that Config project.
This is the command I use in the Pre-Build Event Command Line:
xcopy /Y "$(ProjectDir)$(ConfigurationName)\*.config" "$(ProjectDir)"
xcopy /Y "$(ProjectDir)$(ConfigurationName)\*.cscfg" "$(ProjectDir)"
Every other project in the solution links to the configuration files from the root folder of the Config project.
I also use config transformations as well, for Production vs. Non-production environments. Everything non-Production (local development environment, Azure-QA development environment) has a lot of debug and tracing built in - errors are returned completely to the clients/etc. Production environment has that locked down.
Edit: wrote a blog about this finally: http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx
As Brent pointed out, it is not a good idea to have Staging area to be a full-blown Testing site. It is more geared toward a quick smoke test as well as a great way to deploy a new package into Azure without taking your main site down. (IP swap between Production and Deployment usually does not cause any issues to users)
Hope this helps
First a question, are you referring to configuration settings in the traditional configs? Or in the cloud service config (cscfg)?
If the later, then ATM I'm not aware of any support for configuration transformation. The approach I've seen most folks taking is to maintain number configuration files and use the appropriate file when doing your azure deployment.
This subject also touches on usage of the "Staging" environment. I've seen some folks using it as a parallel testing environment. In practice, its more affective to use it as a staging area to smoke test a new deployment before rolling it into production. If you have a need for a longer term test environment, I've found it better to deploy those services to their own unique namespaces that are then sandboxed away from the production services.
This again touches on ALM best practices for Azure (versioning, deployments, etc..). Something I believe the PNP team is working on and will hopefully have recommendations for soon.
Like knightpfhor said, you can use Visual Studio config transformations if you edit the .ccproj file manually. My answer to a similar question lists the minimum number of steps required to get transformations working.
You can use CloudConfigurationManager in Azure SDK 1.7 http://msdn.microsoft.com/en-us/LIBRARY/microsoft.windowsazure.cloudconfigurationmanager
This starts by looking in the ServiceConfiguration.cscfg e.g. ServiceConfiguration.Cloud.cscfg for config setting. If it isn't there it falls back to web.config and app.config
For example
CloudConfigurationManager.GetSetting("StorageConnectionString")
Will look in the appropriate cscfgfile for StorageConnectionString setting, then it will search the web.config and then app.config.
The simple answer to your question is yes, but you have to mess around with the .ccproj file manually to do it. A full description on how to to do this can be found here
Shamefully, we use TFS at work for a C# project. I wish we could move to svn or git, but we can't change that. All of us working on the project hate the automatic check-out "feature" of TFS, so we checked in our solution and project files as unbound from TFS.
Now, whenever we open the project, we get the following message:
The solution you have opened is under source control but not currently configured for integrated source control in Visual Studio. Would you like to bind this solution to source control now?
Is there a way to disable this message while keeping the solution unbound from the buggy and annoying integrated source control?
The message you reference has nothing to do with TFS, it has to do with integrated source control within Visual Studio. If you really want to get rid of this message, go to Tools->Options->Source Control and set your source control provider to "none."
Then, go and download the Team Foundation Power Tools and enable the shell access, and you'll be able to right click within Windows Explorer and check in from there. If you don't want to do that, you can do your check-ins from the TF.EXE command line.
But seriously, if you don't like the automatic check-out, then just turn that off. You have the option of having TFS automatically check out, prompt you for check out, or do nothing and leave the files in a read-only state until you explicitly check them out.
Another possibility could be to move to a 'git-tfs' combined solution. You would move your team to git, and sync with TFS on a regular basis. This way, only one person has to live with the TFS annoyances.
I have no experience with that, but apparently it has been tried before
If you like the svn/git model better, then I honestly wonder why you would want to turn off automatic checkout? You can configure VS to silently check out files on edit. This comes pretty close to the svn way of working, no?
Also, ensure that the TFS server is configured to allow multiple checkout on all text-based files, and you should be good to go. You can also install your own diff and merge tools (e.g. TortoiseDiff/TortoiseMerge) if you want.
I'm getting the build error 'error VCBLD0007: Could not find project configuration RELEASE|X64 to build.' when attempting to build in that configuration. Release|Win32 works fine. The configuration definitely does exist in the project. I'm building with vcbuild in VS2005 and running on a x64 box.
Anyone have a hint?
I think your error sounds like one I had a while ago. It turned out to be that we had forgotten to install the 64 bit options when we installed. One way to test was to rerun the installer and choose the change or remove and see if the 64 bit options are already installed or not.
My advice in general in such a situation:
Remove the configuration concerned ("RELEASE|X64") permanently, save and quit visual studio.
To do so, you must choose < Edit...> in the platform popup menu from the configuration manager.
Then restart and and re-create the configuration completely. It might be a good idea, to create some screen shots from the old config before removing it.
That might take some 30 minutes, but it probably will solve the problem.
Just a guess: case sensitivity. Or it could be that the project/solution files are malformed. Check them out - they are simple text files. It would be best if you could provide them here, but I understand that it might not be possible.
Also, in case you don't know this (VS is not very intuitive about this), here's a quick explanation of how the configurations work:
There are two kinds of configurations - each project has its own set of configurations, and the solution has a set of configurations. Each project configuration describes how to build the specific project - compiler options, which files to include, etc. Each solution configuration however only describes which projects to build, and which project configuration to use for each specific project. Note, that there is no 1:1 mapping between project configurations and solution configurations. You can set them up any way you like.
The error seems to suggest that the solution configuration you are using references a project configuration that does not exist in that particular project.
This error was occurring because the 64-bit tools for Visual Studio were not installed correctly. A reinstall fixed my issue.