When debugging a nasty problem in your code, one of the most helpful things you can get is a minidump. With that picture of what your app was doing at the time of the crash, hang, or when the memory started spiking, you’ve got a big hint to jumpstart your exploring. While there’s a bunch of tools out there, such as the wonderful ProcDump, and the debuggers themselves to create minidumps, the real moment of truth is when you have to look at those minidump. That’s easy to do with one or two, but what happens if you have 200? In my line of work, where I debug other’s software problems (and will be glad to help you with yours), I’m routinely faced with hundreds of dumps from a client. As much as I would like to carefully open each minidump and lovingly type the same commands over and over for the greatest consulting billing statement ever, I just can’t get my clients to pay for that.
What I really need is a way to say, “Here’s a bunch of .DMP files; go run these WinDBG commands across all of them.” It turns out that accomplishing that basic task is not hard at all when you combine a little WinDBG knowledge with a little PowerShell magic.… Read more
Now that Visual Studio 2015 RC is fresh off the build machines and available for everyone, I’ve updated my Wintellect.Analyzers project (http://johnr.us/1bEO4h8) with full RC support. Go forth and add them to your project so you can get the benefit of advanced compiler analysis and code fixes. To add the analyzers, hit up your Package Manager Console with the following command:
I guess you could go through the fancy new NuGet window in Visual Studio, but you want to be hard core and use PowerShell in VS!
If you’re interested in writing your own analyzers, as I have discussed previously, you’re immediately going to run into errors and warnings with projects based off the default Roslyn template when you try to install your analyzer masterpiece. Here’s what you’ll see:
Attempting to gather dependencies information for package ‘Analyzer126.96.36.199′ with respect to project targeting ‘.NETPortable, Version=v4.5, Profile=Profile7′
Attempting to resolve dependencies for package ‘Analyzer188.8.131.52′ with DependencyBehavior ‘Lowest’
Resolving actions to install package ‘Analyzer184.108.40.206′
Resolved actions to install package ‘Analyzer220.127.116.11′
Adding package ‘Analyzer1 18.104.22.168′ to folder ‘c:\junk\code\Analyzer1\packages’
Added package ‘Analyzer1 22.214.171.124′ to folder ‘c:\junk\code\Analyzer1\packages’
Added package ‘Analyzer1 126.96.36.199′ to ‘packages.config’
Executing script file ‘c:\junk\code\Analyzer1\packages\Analyzer188.8.131.52.0\tools\install.ps1′
Get-ChildItem : Cannot find path ‘C:\junk\code\Analyzer1\packages\Analyzer184.108.40.206.0\tools\analyzers\C#’ because it does not exist.… Read more
My deep abiding love of Roslyn continues! I just published a new video Writing Roslyn Analyzers and Code Fixes up at WintellectNOW: https://www.wintellectnow.com/Videos/Watch?videoId=writing-roslyn-analyzers-and-code-fixes. My goal was to take you from zero knowledge of Roslyn to writing a real world analyzer and code fix in 1.5 hours. This video covers everything from using the Syntax Visualizer to developing and testing analyzers and code fixes. Along the way I show how I solved some of the hard real world issues you’ll encounter.
Given that there’s not a lot of documentation on Roslyn I thought this video would help get folks up to speed as we approach the release date for Visual Studio 2015. I would love to hear any and all constructive criticisms you have on the video. What did I do right, what did I do wrong, and what else do you want to see. Sign up for a free WintellectNOW account and post to the discussion area under the video.
Please note that we reserve the right to move the video to subscription required in the future. Given how new Roslyn and VS 2015 are at the time of recording we thought it was good to get the info out now.… Read more
The other day my co-worker Jeffrey Richter and I were discussing my latest infatuation, Roslyn analyzers. As we bounced around a few ideas one came to the forefront; every catch block should throw. This is not a hard and fast rule, but eating an exception, especially accidentally, has caused more bugs in .NET than we all care to count. My mind started spinning thinking that I want to see if I can automate checking for eaten exceptions in a Roslyn analyzer.
At first glance, the idea seems pretty easy. Look for the catch blocks and look to see if there are any throws, returns, or, goto statements. (Realizing that you can use a goto in a catch block made me involuntarily shudder.) Anyway, sketching through a quick algorithm of going about analyzing the syntax nodes made me realize there was going to be nothing quick about it. This was going to be a lot of work, especially when you really start thinking about all the ramifications. While I welcomed the challenge, I thought I better look deeper at the Roslyn API to see what it offers. Fortunately for everyone, there’s a super nice control flow analysis engine built right into Roslyn.… Read more
Mark your calendars for May 14-15, 2015 for the free 2015 Microsoft MVP Virtual Conference. This is a Microsoft sponsored conference where Microsoft Valuable Professionals (MVPs) will be presenting five different tracks for world wide consumption: IT Pro, Developer, Consumer, LATAM (Spanish), and Brazil (Portuguese). Obviously, I’ll be in the Developer track, but I’m really excited about the multiple language tracks. Making development and IT more welcoming to non-English speakers is awesome.
I’ll be presenting the following session. Go register today.
Roslyn for Normal Developers: It’s Not Just for Compiler Geeks!
You have no doubt heard about Roslyn, the new C# and VB.NET compilers in Visual Studio 2015, and you are probably wondering what they mean to you as a normal developer especially since you don’t have a PhD in Compilerology. In this demo only session you’ll see that no matter the type of .NET development you are doing, Roslyn will quickly become one of your favorite tools. You’ll learn how to leverage Roslyn analyzers and code fixers to fix problems in your team’s code as its being written. You’ve dreamed about having super smart editors that find the bugs before you check in and Roslyn is the answer!
After this session, you’ll know how to develop, test, and deploy your own Roslyn analyzers and code fixers to ensure your team is coding correctly and using your architecture the way you want all by leveraging the actual compiler.… Read more
Over the last few months I have been having a wonderful time developing Roslyn analyzers and code fixes. You can find all the Wintellect.Analyzers code at Wintellect’s GitHub page. If you would like to include these analyzers in your own Visual Studio 2015 CTP 6 project, install the NuGet package by executing the following in Visual Studio’s package manager console window:
Now that I’m getting more fluent in analyzers and code fixes I wanted to share some of the things I’ve learned to save you some time when you start doing your own in the future. First I’ll go over some of the new analyzers I’ve written. Next I’ll turn to the question of using analyzers and code fixes as NuGet packages vs. a Visual Studio VSIX. Finally, I’ll jump into some of the development aspects of analyzer and code fix development where I’ve had issues. Obviously, in that section, I’m assuming you know something about Roslyn and analyzer development. If this is all new to you Alex Turner’s two part series in MSDN Magazine gives you a solid understanding quickly: Part 1, Part 2.
I happened to be working on a C# Roslyn code analyzer and being cognizant that not all the world speaks English, I went through the five minutes of work to internationalize the analyzer DLL. Add the .RESX file and you’re pretty much done. All my unit tests ran perfectly as did the tests of running the analyzer as a .VSIX. However, when I ran the tests with the analyzer in a NuGet package, I kept getting the compiler crashing with a FileNotFoundException trying to load the <assemblyname>.resources.dll file. After spending several hours trying different attempts at working around the problem, it finally dawned on me, I had run into this same bug many, many years ago.
Even though you have the resources in the assembly, that’s not the default place .NET looks. To tell .NET to look in the assembly, you have to specify in your Assembly.CS file the following:
That’s all there is to it. Why .NET resource searching doesn’t always look in the assembly by default is beyond me. Now that the Core Framework is open sourced, maybe I should submit a patch!… Read more
As I was building up a moderately complicated pipeline in PowerShell, I was having some trouble and really wished there was a way to single step the pipeline so I could see the state of each item as it was processed. I wasn’t sure this was possible, but it is and I thought others might find it helpful. The magic is in the super powerful Set-PSBreakpoint cmdlet.
Because Set-PSBreakpoint can create breakpoints on not only lines and variable reads/writes, but also commands, I thought I’d try setting a breakpoint in the PowerShell console on one of the commands in the pipeline and it worked great! In the example below I will set a breakpoint on the Get-ChildItem cmdlet and when the breakpoint is hit, use the command line debugger to step through parts of the pipeline (the ‘s’ command is step into)
When I first saw the Roslyn compiler, I was thrilled! For once the compiler was not going to be a black hole where source code comes in and on the other side of the worm hole a binary comes out. With open extensibility there’s going to be some amazing tools developed that were impossible to do any other way. With this week’s release of the Visual Studio 2015 Preview, the Roslyn API is solid and ready for extension!
We have posted on Wintellect’s GitHub account our first five analyzers and code fixers we wrote to explore that part of the API. They should give you a good idea how to get started writing your own new rules. Here’s the initial set of rules:… Read more