Our team works in C# and has recently updated to Visual Studio 2019 Professional. We are attempting to use Live Share for TDD.
While we can see one another typing, the remote user cannot build or run unit tests.
Am I missing a configuration?
Edit 1
I know this is an old post at this point. It seems that Microsoft sacrificed usability for security. The only thing that you can do with LiveShare is write code together. The person coding tests cannot be remote (AFAIK). Also, to do pair programming it will kind of work in a bad way (i.e. the navigator can make changes but the driver will not necessarily see them especially if they are in another file unless explicitly told where to look). When it is time for the driver and navigator to switch, it almost seems easier to push the code to a repo, terminate the live share session and have the new driver pull it and start a new live share session.
As far as mob programming, this really seems to fail to scale.
Related
I have VS2010 professional and Im working with a large code base that Im unfamiliar with. I want to know what code gets executed when a certain event occurs (namely, when I click a specific button). I know this could easily be done with Intellitrace, but that requires an Ultimate subscription (which is outrageously expensive). Is there any other way I can do this? Ideally without installing anything new (even if its free), but thats not a deal breaker.
You can see what .NET code is executed with Runtime Flow (developed by me, 30-day trial).
Just wondering my browser keeps asking if I want to stop debugging every time I hit browser link refresh very annoying as is slowing down devtime.
Has anybody else come across this?
cheers
Updated Answer, Root Cause Now Found
After what is now TWO years of seeing this error on and off I finally understand what's causing this. A BIG Thank you goes out to Damian Edwards for mentioning this in a community stand-up!
As a developer, we often do all of our development in Visual Studio in Debug mode rather than release mode. And it's very common for us to run our projects with F5. In this case VS runs the project with the debugger enabled, no surprise there.
So it turns out, the "Do you want to stop debugging? error dialog when you try to refresh via browserlink is saying is "Hey you made some changes that look like they might require recompiling the razor view in order to refresh the page, and in order to do that Visual Studio needs to stop the debugger session, is that OK?"
And the fix? This is gonna blow your mind. When you want to use browser link to rapidly refresh the page while doing html/css changes and never see this message again, do this: run the project using CTL+F5 instead of F5. This will run the project without firing up the debugger and you probably weren't gonna use the debugger anyway if you were planning on doing a bunch of html css work on a view using browerlink. :-) That's it, no more error message. Bam. You're welcome. (It took me T W O Y E A R S to figure that out. Hand against forehead, eyes rolling)
I have left my original answer below because it did seem to help in some cases and it has already received a couple upvotes, but in hind sight, I think it was more of a coincidental observation than a root cause..
Original
I have been struggling with this issue for nearly a year. I may have just discovered the cause. I was running two copies of visual studio, each with different web projects, at the same time. Then when I try to get browserlink to refresh the browser in one copy of visual studio it asks “Do you want to stop debugging”.
I then quit out of the 2nd copy of visual studio, and re-ran the web project in the first copy of visual studio and when I tried to get browserlink to refresh the browser it worked fine with no prompt. Yea. A better error message than “Do you want to stop debugging” might have been "It looks like you are running two web projects at the same time in different copies of visual studio. Browserlink does no support this, please close one of them."
You may want to check out this post: https://stackoverflow.com/a/21706524/4079626. If you are using an older version of IE (like IE9), then long-polling may be the issue.
Short answer
Browser Link will only use WebSockets on Windows 8 or Windows Server
2012
Longer answer
The following would explain the issue if you're using Visual Studio on
Windows 7, Windows Vista or Windows Server 2008:
IIS (Express) depends on the .NET framework implementation in
System.Net.WebSockets to handle WebSocket connections; as you
can read in the link to MSDN, you simply don't get an actual
implementation of the necessary classes when you install .NET 4.5 on
Windows 7.
So in that case, the server can't agree to the client's request to
change from standard HTTP to the WebSocket protocol, which forces the
SignalR client to use one of the fallback options (in your case:
long-polling).
A small ma and pa shop came to me recently with a request to update a vb6 program one of their former part time employees made for them while home from college. On the cd the student provided is both the source code and a installer for the program, which extremely helps. I would like to just give them a new cd with a new installer and the updated source code. My question is, how do I go about creating or if easier updating a installer for a language that entered "Non Supported Stage" back in 2008?
Update:
Just to answer some of the questions, the updates they are asking for are just changing the wording of some labels and changing one control from a textbox to a combobox. They are a ma and pa shop and don't want to pay the cost to have the app re-written to a newer language, even though it has been recommended.
You're going to need a copy of Visual Basic 6 (or Visual Studio 6) which is difficult. If you have an MSDN subscription, I'm quite sure you can download it from their archive, but if not, you might need to buy a copy. Check EBay. Have the ma and pa shop purchase it at their own expense, and they should own it in case they want to make future changes. You can use it on their behalf to do work for them, if you're the only one using it, and just uninstall it when you're done.
Also, if you have a copy of Visual Studio 2005, technically you can "downgrade" to VS6 but you have to call Microsoft and have them send you the install program, and you're not allowed to use VS2005 concurrently with VS6. Yeah, I know...
Ok, so if you've got that far, get the source on your computer and get it under source control. I suggest Mercurial (specifically the TortoiseHg client). I've had lots of luck with it on a VB6 project, and it's free. (Don't use SourceSafe, even if it comes free with VS6!) The distributed nature of the Mercurial repository means you can hand them back a CD with the entire repository on it, and the next poor sap who has to make changes will at least be able to do a diff and know what you did.
As someone else here said, VB6 has a built-in utility for making install programs, but I think you had to have the Enterprise version for that. It's worth finding that out before you get a copy.
Now go ahead and make changes, but be very careful. Remember that you probably don't have any unit tests, so you're likely to break stuff. If you want to be professional about it, there are unit testing frameworks out there for VB6. For instance, vbUnit. Again, I suggest having the customer buy a copy (about $99 for a single developer seat, I think). If the change was anything more than changing the company logo on the splash screen, then this is something I'd invest in. Write tests that cover every module or feature you're going to change. If all the logic is in event handlers in the form itself, carefully remove the code you need to change out into modules that you can write unit tests for. Write the tests to verify the current functionality first.
Then go ahead and make your changes. If you've gone to the trouble of setting up a testing framework, then you might as well use some TDD and write your tests first. Write a test, make sure it fails, write enough code to make it pass, and repeat.
All of this still requires you to have a solid manual test plan to check the functionality at the end. That means you need a solid grasp of what it does. You can pretty much assume that no matter how careful you are, you'll break something you didn't understand. Make sure to give yourself enough time to fix other problems that pop up after you deliver it.
I recommend against re-writing it in .NET unless it's a really simple program with only one form. The effort likely isn't worth it.
Caveat: beware of 3rd party components the original programmer might have used, but not included on the CD. If they used some ActiveX or COM stuff that they purchased from a 3rd party, but they didn't license it to your customer, you might have to end up purchasing it again just to get it to compile.
EDIT:
Based on your extra information, if you're really just changing a couple of controls and wording, then I think you can get away without a unit testing framework. I would definitely use some source control though.
I do remember using the Package and Deployment Wizard, and I agree it sucked. I actually used a 3rd party installer, now that I think about it. However, if the changes are small and the original application used the PDW, I'd probably stick with that.
You Can Convert VB6 projects to .NET.
If you have Visual Studio 2005 or higher...
Or the worse case is re write the code using VB.NET.
Go to this Link.
Convert VB6 - .NET
If I recall correctly, Visual Studio 6 came with a rudimentary wizard for creating an installation program for a VB6 application. So, assuming that you have Visual Studio 6 installed for VB6, there should be an installer wizard that you can use. However, it may have problems deploying the VB6 runtimes on Vista or Win 7 machines. Perhaps another SO guru will have the answer to that one.
You can also use the freeware Inno Setup to create an installer for a VB6 application. More information can be found here. However, it requires more manual effort than what came with Visual Studio.
If taken from a developers perspective, what would my team and I gain from using Visual Studio Team System and Visual Studio Team Foundation Server?
I can see some features and the like, but what have you gained from using the two versus using VS Professional and SVN (for a weak example). If there are any good links that you know of, please feel free to post them.
Team suite will allow you to manage the entire lifecycle management in a unified framework.
It is very easy to bind your changes and source code to a build, work-items, create release notes, etc.
Well, lets talk 2010... ;)
You can not compare Prof + SVN with TFS and TS - reason is you msis out a LOT. The comparisong would have to include some other technologies toget on feature parity.
IMHO good points are:
Good source control (including stable server based storage, proxies for external subteams etc.). Not saying SVN sucks, but I dont like not having locking checkouts on times, and if you run a larger / distributed team, the proxy functionaltiy really pushes performance.
Automatded build / Continous integration (which is where CC.NET or TeamCity would come in). Unless you dont do that, plus unit testing etc. - you simply did not mention any solution for this, and in TS it is integrated, which I take as a big plus.
Gated checkin (check in only after build server ok's the changes - harder to break builds)
Bug tracking / work item tracking (not the best, but again - you need another product for that). I personally think it does a mediocre job there (Axosoft OnTime looks a lot better), but - well... it is integrated ;)
Data Dude - database change script generation and handling of database versioning. Again, this is a big problematic area otherwise - third "another piece of software needed" thing.
That is a decent start at least to show you that the comparison is a lot more complicated.
Is anyone out there using Team Foundation Server within a team that is geographically distributed? We're in the UK, trying work with a team in Australia and we're finding it quite tough.
Our main two issues are:
Things are being checked out to us without us asking on a get latest.
Even when using a proxy, most thing take a while to happen.
Lots of really annoying little things like this are hardening our arteries, stopping us from delivering code and is frankly creating a user experience akin to pushing golden syrup up a sand dune.
Is anyone out there actually using TFS in this manner, on a daily basis with (relative) success?
If so, do you have any hints, tips, tricks or gotchas that would be worth knowing?
P.S. Upgrading to CruiseControl.NET is not an option.
Definitely upgrade to TFS 2008 and Visual Studio 2008, as it is the "v2" version of Team System in every way. Fixes lots of small and medium sized problems.
As for "things being randomly checked out" this is almost always due to Visual Studio deciding to edit files on your behalf. Try getting latest from the Team Explorer, with nothing open in Visual Studio, and see if that behavior persists. I bet it won't!
Multiple TFS servers is a bad idea. Make sure your proxy is configured correctly, as it caches repeated GETs. That said, TFS is a server connected model, so it'll always be a bit slower than true "offline" source control systems.
Also, if you could edit your question to contain more specific complaints or details, that would help -- right now it's awfully vague, so I can't answer very well.
We use TFS with a somewhat distributed team - they aren't too far away but connect via a slow and unreliable VPN.
For your first issue, get latest on checkout is not the default behaviour. (Here's an explanation) There is an add-in that will do it for you, though.
Here's the workflow that works for us:
Get latest
Build and verify nothing's broken
Work (changes pended)
Get latest again
Deal with merge conflicts
Build and verify nothing's broken
Check in
[edit] OK looks like you rephrased this part of the question. Yes, Jeff's right, VS decides to check some files out "for you," like sln and proj files. It also automatically checks out any source file that you edit (that's what you want though, right? although you can change that setting in tools > options > source control)
The proxy apparently takes a while to get ramped up (we don't use it) but once it has cached most of the tree it's supposed to be pretty quick. Can you do some monitoring and find the bottleneck(s)?
Anything else giving you trouble, other than get-latest-on-checkout and speed?
From my understanding you can have multiple TFS Application servers in different locations. They either can both talk to the same SQL Server or you could use SQL Server mirroring. Having your own local TFS server would likely speed up your development times.