Using C# 3.0 from .NET 2.0

by Matt 4. June 2007 18:32

I'm looking forward to Orcas. It's a (mostly) additive release, similar to 3.0. The CLR itself doesn't really change (there is a service pack level update, but you're essentially still running v2). There are updates to the compilers, the IDE and new libraries that add to .net 2 and .net 3.0 (such as System.Core.dll).

One of the nice things Orcas allows is "multitargeting", where you can target different versions of the framework (2.0, 3.0 or 3.5). Of course, if you're targeting a down-level version, you'll lose support of that framework version's assemblies (e.g. no WPF apps in a 2.0 targeted application). What might not be obvious is that the compiler still supports the 3.5 features, including the nice LINQ "select ... from ... where" syntax (although there's a caveat around that one).

Thanks to Daniel Moth for all this info!

Tags:

.net tools

Xml Diff and Patch tools redux

by Matt 28. April 2007 17:13

If you fancy saving yourself a small world of pain, you can get Microsoft's xml diff and patch assembly simply by installing Microsoft's Xml Notepad 2007. Works fine on Vista.

Now, you only get the assembly and not the command line executables or the source, but if you need a copy to use programmatically, this is the way to go.

The whole point of getting that thing installed was to evaluate the sample which created a html representation of the diff. To add insult to injury, it's built into Xml Notepad.

I'm still not decided on if it was worth the effort. More later.

Tags:

.net tools

Xml Diff and Patch tools

by Matt 16. April 2007 17:35

Ages ago, I found Microsoft's xml diff and patch tools on gotdotnet. Dead useful little package - it does exactly what it says on the tin, diffs and patches xml files.

I went looking for it again today, and of course, link rot had set in. Microsoft is phasing out gotdotnet, so when you head on over to http://apps.gotdotnet.com/xmltools/xmldiff/ you get an "Unspecified error" page, with no helpful links. Bit of a shame, that, seeing how loads of pages around the web point you there.

Fortunately, there are a couple of msdn articles. The first gives a nice overview of using the xmldiffpatch assembly in your own code, but not of the tools. And the link to download the tools returns an out of date 1.0 version.

But, that download has a sample to generate a html file from two differing xml files. And this second msdn article creates a Windows Form app over the top of this sample to generate and display the differences in a hosted browser window. Again, this uses an out of date 1.0 version.

Finally, I look at the home page of www.gotdotnet.com (which still has people uploading samples even though it's being decommissioned) and find a link to the XML tools page on msdn. Now, we get the newer 1.1 version. (There's also a link to the quite useful Xml Notepad on that page.)

And it doesn't install on Vista.

It's demanding .net 1.1 to be installed.

Keep me covered, I'm going in.

First, we need to open the executable in Visual Studio. This should display the resource view. Expand the RCDATA node, and right click on "CABINET". Export this data as "cabinet.cab". Switch back to explorer, and double click on the .cab file. You can now copy out setup.exe, setup.ini and XmlDiffPatch.msi. In fact, we're just interested in the .msi file. If you double click on it, you get an error message that .net 1.1 isn't installed.

I can't find a way to fix this easily. The msi file has a custom action that checks for the installed .net framework versions, and compares them against a property it has stashed away. It would be nice if we could have just changed the SupportedRuntimes value in the setup.ini, or passed in an override value for the VSDSupportedRuntimes property on the command line, but no. We have to edit the .msi file. You'll need Orca installed (I think it comes as a .msi in the Windows SDK). Open the .msi file, scroll down to "CustomAction" and delete the VSDCA_VsdLaunchConditions custom action. Save the file and exit.

Double clicking the .msi will now allow you to install the software. Phew.

It seems to work, but bizarrely, the XmlPatch.exe file gains the Vista UAC shield. I guess because it's got the word "patch" in the name (and because it's in the Program Files directory. Copy it out, and it's fine). That's a bit pants. To fix that, you'll need to copy the following into a file called XmlPatch.exe.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="XmlPatch.exe" type="win32"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"/> 
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

Then drop to a command prompt. Seeing how you've already got the Windows SDK for Orca, you'll also get mt.exe from there. It should be the latest version (there are bugs in previous versions which can cause blue screens!). Run the following command line, using the mt.exe from the SDK:

mt -manifest XmlPatch.exe.manifest -outputresource:XmlPatch.exe

Finally, we've got a version of the xml diff and patch tools, ready to use. And it even comes with source. Installed to Program Files so that you can't compile it without moving it, but you've got source code. You can now build the all important dll, the XmlDiff and XmlPatch command line utils, and there's that sample that generates a html diff view for you. This was the sample I wanted to build, and what caused all of this pain. It'd better be worth it.

Tags:

Vista | .net tools

More than one FxCop tip

by Matt 8. April 2007 18:02

FxCop is pretty useful. No, really. Automated code review type thing. Sort of. And here I am about to give you the best FxCop tip in the world. Well, actually the best two FxCop tips. Ok, make it three. Ah stuff it, here's a whole bunch of them.

First top tip - unless you're using the version of FxCop that's integrated into Visual Studio (I'm not), you'll want to define the CODE_ANALYSIS symbol in your project settings. This is because the SuppressMessageAttribute class is decorated with a ConditionalAttribute with the CODE_ANALYSIS symbol. In other words, the SuppressMessage attribute will be ignored unless you define CODE_ANALYSIS. (Only define it for debug projects. Consider that a bonus tip.)

(Of course, you might actually want it to be ignored to stop over-zealous/lazy programmers suppressing FxCop violations instead of fixing them. But hey, let's try and stay glass half full, eh?)

Here's one I prepared earlier - ensure your spell check language is consistent across all users. And the top up tip is to ensure that you're all on the same version (and service pack revision) of Office.

The FxCop team blog provides a way to run FxCop as part of a normal build, including a bug and workaround. But this doesn't use a project you might have set up, so you might want to give the FxCop msbuild task from the MSBuild Community Tasks Project, or just play about with the /project command line option. (This blog post has more details on FxCop/Visual Studio integration, including a link to an FxCop addin, that I'll have to have a look at.)

Speaking of projects, FxCop bizarrely saves the messages to the project file after each run. The advantage of this is that you get to see what's changed between runs, with new messages displayed in bold, but you do need to have the file checked out each time you run an analysis. If you don't want this, uncheck the option to save Active messages in the project. You still want to keep exclusions checked though - that's a change that you do want saved. Alternatively, you can save active and excluded messages to the report file and use the /import switch to FxCopCmd to get it to read those files. This way, your project file doesn't have to change at all, but managing the reports in source control could get tricky. (I feel a post analysis script coming on...)

I think that last paragraph can be summed up simpler - read the docs. Or at least, read the "Managing FxCop Projects" page. It's dead easy to get started with FxCop, but once you start to get a bit more advanced, it's not terribly obvious what's going on. And if you're putting FxCop into a build process, you'll really want to read through "Using FxCopCmd".

But the number one best FxCop tip? Simple. Run it from day one. Don't let the violations back up, or you'll never bother to clear them down.

Tags:

.net tools | FxCop

FxCop spell check language

by Matt 24. August 2006 16:02

We had discontent on the team today. Can you believe people actually dissing FxCop? Turns out they were just upset about the spelling - it's making us spell in American English, rather than British English.

I can feel the pain - it still makes me wince whenever I see "Favorites". And it's just wrong to spell it "color".

Easily fixed - simply change the spell language in the project options dialog.

Or, if you never use the GUI (e.g. if you've gone continuous integration crazy) then it's in the .fxcop file. It's a normal .net locale; "en-gb", "en-us" or just plain "en". (//FxCopProject/ProjectOptions/Spelling[@Locale])

One thing that isn't surfaced in the UI is that you can specify multiple locales to check. Simply provide a comma separated list of locales. FxCop will try to match each word against the first in the list. If it doesn't match, it moves on to the next locale. Handy.

Thanks Reflector!

Tags:

.net tools | FxCop

Rel=Me

Month List

RecentComments

Comment RSS