Good idea, Craig. That's added now. Sorry to hear that caught you out; it's not unreasonable to capitalize SSMS!

Recently started using SQL Source Control and it's proved a fantastic product.
Needed it with multiple instance support so updated to the latest version, this worked fine on Windows XP development workstations however did not work on Windows 7.
I realise the documentation does state the tag as <AllowMultipleSsms> however we found that it does not work under Windows 7 Pro 64Bit SP1 with SSMS for SQL 2008R2 (SSMS v10.50.1617.0) when it's entered as <AllowMultipleSSMS>.
We weren't expecting the case sensitivity, perhaps a helpful note against the documentation stating this needs to be so?
Thanks for a great product though.

Just finished testing this out and everything looks great. Nice job guys!

Thanks Anonymous. We'd like feedback from anyone and everyone who's tried this build! Does it work how you'd expect? Are there any problems with it?

I'm just going to install the beta to try the functionality out. When you say feedback, is that feedback from anyone or special beta testers?

I too would like the ability to use this with multiple instances of SSMS. Point being, running two instances using runas /netonly to point to two separate domains as Linda stated. Besides the fact that it's just some people's preference to use separate instances.

I work in a team of developers. All of us tend to have multiple instances of SSMS open for various reasons The abiltiy to have source control available in all instances would definitely be helpful.

I also use multple monitors to be able to keep up both environements at the same time on different monitors

I use multiple instances of SSMS as we have 2 domains and frequently use different SSMS to prevent running script on Production instead of our test environment. I also connect to the 2nd domain in a second instance of SSMS as they are 2008 R2 and most and the servers in the local domain are 2005 so I use the different versions... I know I could connect to both with the new SSMS but I still prefer to use separate instances of SSMS for the different environments, even if it's the same tool

This happenned to me after SSMS crashed.
When I relaunched it, SQL Source Control tab kept telling me that.
Even if I closed it and re launched.

I believe this happenned because the crashed one remained in my computer's proccess and was conflicting with SQL Source Control Tab

David, Yes we want to have our cake and eat it too!

I share the same problem quite regularly as well. Fix is to close down and re-open SSMS.

I get this error after closing SSMS and then reopening it. I even stopped and started the SQL Server and I'm still getting it. (SQL Server 2012)

I also agree with the convenience of multi-instance support but more importantly, if it's not going to be supported, related-bugs need to be squashed (like SQL Compare opening a new instance of SSMS and causing confusion).

ADMIN: Connecting to multiple servers in one instance isn't the same as having two instances of SSMS open (though I do see that many people here don't appear to realize they can connect to more than one server instance per SSMS instance). Even the ability to break windows out of SSMS isn't nearly as clean has having fully independent SSMS instances.

I run with 4 monitors and as cheap as they are these days, I'm willing to bet that single-monitor developers that fit your target audience are fairly uncommon or at least the rest of us make up a significant user-base.

@David - as far as I'm aware there were some architectural issues that would have been expensive to address. In the early stages of the tool we were unsure what the appetite would be for database source control so we decided to release with the limitation. Now that it's clear that there's a strong demand, we should consider trying to address this, but as ever it's just one of many valid feature requests on our backlog!

This seems like a very odd omission. What's the rationale behind this?

I can't reproduce this. I've opened SSMS(1) and SSMS(2). SSMS(1) has the working SQL Source Control. I close SSMS(2) and I can successfully commit changes with SSMS(1). Or are you hoping that the disabled one enables itself when it's the only one remaining?

Having two (or more) ssms windows open is a constant need for me. It especially helps keep production changes separate from development changes.

This would be extremely useful, as we all have traditionally worked with multiple SSMS windows open, and now we have had to alter our behavior to conform to SQL Source Control requirement.

A must for me too. I always have multiple projects open (I'm a shared service :-). Some are in SSC some aren't, so I run into Jordan's probelm all the time, when I close the magic SSMS instance with SSC running in it.