Archive for June, 2007
Xiine is “da bomb” for digital content!
Posted by claudiolassala in Software Development on June 28, 2007
I’ve been addicted to reading content in a digital format, such as articles and books. I like the ability of being able to carry a boat load of books in my laptop so that I don’t have to carry the printed copies around. I also like being able to search content within a book. For those reasons I got used to reading on the screen. However, most of the formats available out there aren’t really that great.
For instance, PDF files don’t allow for a reading experience that flows well; you’re always jumping back and forth in a multi-column page, which is annoying. Also, the images are usually small, and you can’t really zoom into it. If you zoom it into the document itself, things don’t scale up well, with both images and text pixelating and looking really fuzzy. Besides all of that, there isn’t a good way to organize a library of PDF files.
I know there are other formats out there, such as HTML content, but I can’t say those are any better than PDFs.
Something really exciting is Xiine!! If you haven’t seen it yet (or "xiine" it yet), check out Markus’ post about it, where you can find a lot more details than what I’m putting here.
Besides the cool factor that Xiine is built using technologies such as WPF, WCF, and ClickOnce, this product also addresses all the things I’ve mentioned above about PDFs.
The one thing I’m looking forward to get into Xiine is some magazine for guitar players. I used subscribe to a few guitar magazines, but the one thing I hate about them is how they handle advertisement. I mean, you start reading an article, and then at the bottom of the page, they print something like "article continues on page X…". Then, they throw a bunch of pages with advertisements right after that, so you have to make big jumps to be able to read an article in its entirety. Not only that, but when you go to page X, they very often manage to make more than one article going to the same page, so you end up with one column on that page as the follow-up from one article, and another column as the follow-up for another article. Ouch!! I absolutely hate that.
I mean, they could put the advertisements at the end of the magazine, or at least, in between articles (and not within an article). If I could only read the article entirely without taking these jumps, I’d gladly look at the advisements wherever they were. However, because I get so mad at this, I refuse to look at the advertisements at all!
Another thing I’d love in such a magazine in Xiine with be to not only have the article where some guy explain some guitar technique, but it’d be great if I could click on a snapshot and see a video where the guy shows the thing he’s talking about. Well, maybe someday they’ll get there.
Bottom line is: the technology is here, and it’s really cool!! And of course I’m a little biased to talk about Xiine, but you really should check it out. 🙂
Compiling static analysis rules targeting both FxCop and Visual Studio
Posted by claudiolassala in Software Development on June 27, 2007
We have a bunch of custom static analysis rules that we wrote here at the company. We have to make them available for use with both FxCop (the stand-alone tool) and Visual Studio (the Team System edition that supports code analysis). In order to support the rules in both scenarios, they must be built against the specific APIs (either the FxCop or the Visual Studio versions). That means when I build the rules, I need to make sure I add references to the right assemblies. To facilitate this, I’ve changed the MSBuild files to pull in the right references depending on what build configuration I’m using.
The main assemblies we needed imported are the FxCopSdk.dll and the Microsoft.Cci.dll. The FxCop versions reside under the FxCop installation folder (something like c:\Program Files\Microsoft FxCop 1.35), and the Visual Studio version resides under the VS installation folder (something like C:\program files\microsoft visual studio 8\team tools\static analysis tools\fxcop\).
First thing I did was to create a new MSBuild project file, named FxCopReferences.proj. The content of this file is listed below:
<Project DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <Reference Condition=" '$(Configuration)' == 'Debug' "
Include="FxCopSdk, Version=1.35.0.0, Culture=neutral,
PublicKeyToken=2725db9ba1c53c87, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>
..\..\..\..\..\..\Program Files\Microsoft FxCop 1.35\FxCopSdk.dll
</HintPath> </Reference> <Reference Condition=" '$(Configuration)' == 'Debug' "
Include="Microsoft.Cci, Version=1.35.0.0, Culture=neutral,
PublicKeyToken=2725db9ba1c53c87, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>
..\..\..\..\..\..\Program Files\Microsoft FxCop 1.35\Microsoft.Cci.DLL
</HintPath> </Reference> <Reference Condition=" '$(Configuration)' == 'Release' "
Include="FxCopSdk, Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>
..\..\..\..\..\..\Program Files\Microsoft Visual Studio 8\
Team Tools\Static Analysis Tools\FxCop\FxCopSdk.dll
</HintPath> </Reference> <Reference Condition=" '$(Configuration)' == 'Release' "
Include="Microsoft.Cci, Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>
..\..\..\..\..\..\Program Files\Microsoft Visual Studio 8\
Team Tools\Static Analysis Tools\FxCop\Microsoft.Cci.dll
</HintPath> </Reference> </ItemGroup> <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" /> </Project>
The MSBuild project above defines an ItemGroup with Reference elements. The reference elements use the Condition to determine what kind of Build Configuration is being used: if "Debug", build it to FxCop; if "Release", build it to Visual Studio. Eventually I’ll change that to have FxCop and VS build configurations, but for now, I’m just going with that.
Next, I removed the references to the assemblies that I had before from my rule projects, and changed the project file (csproj file), so that it imports the FxCopReferences.proj file. That means I just added the following line to my csproj files:
<Import Project="..\..\StaticAnalysisRules\FxCopReferences.proj" />
That’s it! This approach gives me a quick way to produce versions of our rules assemblies targeting different code analysis runners (FxCop or Visual Studio, that is).
C#, VB, IL, and FxCop
Posted by claudiolassala in Software Development on June 25, 2007
I was working on fixing some custom static analysis rules here. In one of the rules I check whether a type’s member have XML comments. My rule was reporting a false positive regarding lack of XML comments on the compiler-generated default constructor. Well, we shouldn’t expect the compiler to also push XML comments there, right? 🙂
I poked around to see how I could figure out whether a default constructor was a compiler-generated one, or one explicitly written by the developer. This is what the IL looks like for a developer-created default constructor in C# (notice that I didn’t put any code within the constructor… I just had the simple declaration of an empty constructor):
Next, I removed the constructor, and let the compiler generate one. This is what the IL looks like in such case:
Notice that there are no "nop" opcodes. I though "hey, I can inspect the constructor’s body, and if I don’t find any nop opcode, I assume that’s a compiler-generated constructor!". Made that change to the rule, and it seemed to work like a charm for code written in C#. It did not work for code written in VB, though.
This is what an empty developer-generated constructor looks like in VB:
Notice the nop opcodes in there. Hmm… I guess I can’t rely on that then…
Next, I removed the constructor from the VB code, and this is the IL for the compiler-generated constructor:
Notice that the constructor is decorated with the DebuggerNonUserCode attribute. Well, okay, I kinda like that better. I’ve had my rule changed to test for both scenarios, then; that way I get C# and VB covered. I’ve also improved the rule so that it disregards anything decorated with the DebuggerNonUserCode attribute.
Anyways, I thought it’s interesting that we’re always told that it doesn’t matter what .NET language we write code into, it all comes down to the same IL. Well, not so much. 🙂
Know your shortcuts!
Posted by claudiolassala in Productivity, Software Development on June 5, 2007
I don’t know about you, but I do my best trying to find out about shortcuts, and memorize them. We usually have to think longer trying to get to some functionality, but with shortcuts, the brain just look them up and use them much faster then we can consciously think about it.
When I find out about a new shortcut, what do to memorize it is to make a note of them somewhere. Then, I try to use it every time! If I happen to forget what the shortcut is, but do know that I have it listed somewhere, I’ll go back and look it up, so that maybe next time I’ll remember it. This pays off big time in the long run.
Shortcuts in Windows
Make sure you know at least the most basic ones. There’s quite a few very useful shortcuts in Windows, most of them being triggered as a combination of Windows Key + some other key. For instance, Windows Key + E brings up Windows Explorer, Windows Key + L locks your computer, etc.
You can find a list of those shortcuts here.
Shortcuts in Visual Studio
Visual Studio comes with a lot of shortcuts pre-configured. There are reference posters that lists all the default keybindings for both C# and VB.NET available that you can download. Make sure you get them and try to memorize at least one shortcut every other day (there’s a bunch of them, so take one step at a time).
Visual C# 2005 Keyboard Shortcut Reference Poster
Visual Basic 2005 Keyboard Shortcut Reference Poster
Cross-Application Shortcuts
Be aware that some shortcuts work across different applications (or across different "areas" within the same application). I’m not talking about the default ones such as Ctrl+C and Ctrl+V (you know those right? Copy and Paste?? 🙂 ); I’m talking about things like the shortcut to comment code in or out.
For instance, if you’re editing .NET code in VS, you can use Ctrl+K+C to comment code out, and Ctrl+K+U to uncomment the code (I still don’t understand why those options don’t show up on the right-click menu, and are buried under the Edit -> Advanced menu instead. I just can’t associate commenting code out with advanced). What I did not know until a few months ago, is that you can use the same shortcuts when you’re editing XML files in VS (I used to manually type in the angle brackets, exclamation points and dashes…). And, that one also works in SQL Management Studio when editing T-SQL code!
Claudio Lassala's Blog 