Saturday, September 06, 2008
Imagine you have a bug that happens only in production. You connect to the production server and do a whole pile of exploring, and now you think you know what you need to tweak on your dev box to reproduce the problem and get started on fixing it. Or perhaps you are half way through figuring something out on your own machine and you need to hand over to another developer. Maybe you just want to switch to your laptop because you’re leaving the office. There are many reasons why you might want to copy breakpoints between computers. As you may know, they are kept in a .SUO file (Solution User Options I believe) in your solution folder.
But heavens above, do not try to copy that file from one machine to another! As John Robbins says:
The .SUO file is the bane of your existence. Nearly all the problems you encounter with Visual Studio are the result of a corrupt .SUO file. Sadly, it seems all it takes to corrupt the .SUO file is your heart beating. In other words, whenever you have Visual Studio crash, refuse to debug, or behave strangely it's the .SUO file's fault. Whenever anyone asks me about strange Visual Studio behavior, my instantaneous response is "Delete the .SUO!"
So John took care of this with his own add-in. You can save a set of breakpoints into a little file. You can then move the file between machines and use it to set all those same breakpoints on another machine. Or, probably even more fun, you can set aside the 20-some breakpoints, tracepoints, conditionals and so on that you painstakingly set up for bug A, save them and then clear them all, set different ones for the drop-everything-urgent bug B, and then when B is fixed you can get all your old breakpoints back and return to working on A. John is giving the add-in away, it works for both native and managed code, so go on, get it now.
Friday, September 05, 2008
One of the persistent myths of managed code is that you can’t have a memory leak if you’re a C# or VB developer. You really can. In this intriguing post, Sasha Goldshtein asks "Is it a managed or a native memory leak?" and then shows you some clues to lead you towards an answer.
Thursday, September 04, 2008
While I was at Tech Ed Developers (US) this summer, I spoke with Craig Shoemaker for his Pixel8 podcast. We talk about UI, and Vista, and the usual things. I have some distinguished company in this interview but if you don’t want to listen to Ted Neward you can zip ahead to the 18 minute mark for me.
Wednesday, September 03, 2008
In case you were worried that Microsoft efforts like the Parallel Framework (PFX) would be aimed only at managed developers, leaving native developers sitting at the little kids table again, take a look at the Parallel Programming in Native Code blog. It hasn’t been updated terribly often, but perhaps some feedback would encourage them (or is it just Rick?) to keep it current . The one downer: "this is technology we're currently exploring and I don't have any ship or CTP dates to announce." Stay tuned, I suppose.
Tuesday, September 02, 2008
Tech Ed Developers (Europe) is spotlighting a number of the top sessions from last year, free for anyone to watch. Mark Russinovich (on Wikipedia, his blog) knows more about the internals of Windows than anyone else who’s allowed out in public, and in this session, The Case of the Unexplained... (rated 5 stars out of 5 by attendees), he covers various mystery bugs and how he tracked them down. I’m slightly disappointed that some of the stories ended "so I logged a bug with that team" – I would have loved it if these were all fix-your-config stories, but still to see the techniques is very cool, and if your own code is causing the mystery CPU spike or resource leak, you will really benefit from the tools and approaches Mark shows. Sure, it was at the IT Pro half of Tech Ed, but developers need to know this stuff too!
I would like this stage someday. It's the Barcelona keynote stage, used for wildly popular breakouts also.
Monday, September 01, 2008
Wednesday, July 02, 2008
I enjoyed meeting some friends from the C++ team at Tech Ed and taking a turn in the booth. Li Shao and Marian Luparu were there when I was, and plenty of customers came by. Now you can read a nice summary of the customer conversations on the C++ team blog. The comments keep the conversation going. They are reading, so go ahead and join in!
Tuesday, July 01, 2008
If you have some native code that you have sweated long and hard to create, and now you want to make a shiny new user interface using managed code (WPF probably) or expose the engine to web services (WCF probably) or the like, I hope you know how to do that. Most of the interop discussion out there is focused on that direction. But what if you have a native application and you want to use some cool capabilities from the .NET Framework? Most people really only know how to do it through COM. Your native code can pretend the .NET object is a COM component. But there are other options.
I've referred before to reverse P/Invoke - this is when a .NET delegate is made into a native callback function and handed to native code. It works, but in a way it's still managed-calling-native since the managed code has to start things off by making the delegate and handing it over.
There is a third way. It's a little complicated, but I bet it's faster performing than COM interop, and parts of it could be automated. Essentially, you wrap a C++/CLI managed class around some C# or VB managed class, and then you wrap a native class around that using gcroot<>. It's all explained with diagrams and samples by Sasha Goldshtein. Take a look!
© Copyright 2019 Kate Gregory
Theme design by Bryan Bell
newtelligence dasBlog 2.3.9074.18820
| Page rendered at Friday, October 18, 2019 2:44:49 PM (Eastern Daylight Time, UTC-04:00)
On this page....
Pluralsight Free Trial
Click Start a FREE 10-Day trial