Rob Gillen's WebLog : Visual Studio

Automated Chart Generation

rgillen — Fri, 18 Dec 2009 21:49:23 GMT

It’s late on the Friday afternoon before Christmas week which means things are pretty quiet around the office. This quiet has the net-effect of allowing me to get quite a bit done. The last few days have been very productive with respect to our research project and Azure work (more on that coming soon) which is now in full swing. We are currently working on collecting performance data from our codes running in Azure (and soon in the Amazon cloud) and are also doing some testing of transfer speeds of data both to/from the cloud as well as between compute and storage in the cloud.

I’ve been working to automate much of this testing so we can do things in a repeatable fashion as well has have something that others could run (both other users like ourselves as well as possibly vendors should we come across something that requires a repro scenario). So far, running tests and generating data in CSV or XML format is pretty simple, but I found myself wanting to automatically generate charts/graphs of the data as part of the test process to allow a quick visualization of how the test performed. I spent a good bit of the day looking at old tools for command-line generation of charts (i.e. RDTool, etc.) and none of them were exactly what I was looking for – not to mention my proclivity to using C# and VS.NET tools and my desire to have something that looked refined/polished and not overly raw.

Thankfully, I stumbled upon something I should have remembered existed but simply hadn’t had the need to use before – the System.Windows.Forms.DataVisualization.Charting class. If you aren’t familiar with this assembly, it was released at PDC08 and has a companion Web class for performing similar operations in ASP.NET applications. In my basic testing I was able to build a console application that would ingest the CSV output from my testing harness and then generate some fairly nice looking charts based on that data. The following shows a chart (click the chart to see it full size) generated from ~1800 data points, and automatically generates a 50% band and 90% band allowing the viewer to very easily ascertain the averages and data points. This was generated using a combination of the FastPoint and BoxPlot chart types.

Clouds and Traditional Hosting Companies

rgillen — Wed, 25 Mar 2009 21:14:04 GMT

NOTE: this blog has moved to http://rob.gillenfamily.net Please update your links and feed readers appropriately.

I sat on a conference call yesterday wherein we discussed our thoughts on where the cloud was going and how it was going to impact the “traditional” hoster. Our company has been working with hosters for many years (I started in 2000 and they had been doing it before that) and have seen cycles of service come and go. It used to be that just providing personal web + email was all you had to do to be successful. Then, the “Application Service Provider” (ASP) model started and morphed into providing business-related services and eventually to where companies outsourced entire portions of their infrastructure (think Hosted Exchange, Hosted CRM, Hosted OCS). Throughout much of this, however, locality seemed important – not in reality, but in perception. The vast majority of people would choose to host their services with a company that was close to them, or they had learned by reference from a friend or colleague.

As we walked through the current market directions, and in later conversations on the same topic, I’ve become more and more convinced that unless significant changes are made, the traditional “hoster” is destined for failure. Web hosting, data hosting, email, etc. are all being commoditized by the big boys (read Microsoft, Amazon, Google) making it almost impossible for the small hoster to compete. I expect to see a rise in the number of white label services, and also in the number of mixed-metaphor hosters – What I mean by this last statement is hosters who will present a unified stack of services to their customers and while much of those services may simply be white-labeled reselling of someone else’s services, some key aspects of the “stack” will be provided directly by the hoster. The key is specialization, or niche services. Maybe a hoster offers a specific financial or ERP system hosted and then marries that with services from other vendors.

Another aspect of the call that was interesting to me was the postulation that these hosters were looking for ways to “get into the cloud” – I chuckled a little because they, of all people, understand the benefits of the cloud as they have been cornerstones of such for years. They’ve built their businesses on providing “cloud” hosted services. They understand where the margins are/are not – and know better than most that it’s all about scale. This is precisely why I think that the existing model is in trouble – a moderate size hoster with 1000 – 5000 servers simply cannot compete with the big three who are buying datacenter blocks in shipping container-units – each of which hold between 2000 and 4000 servers.

The game is changing… those who innovate and adapt will be here tomorrow to talk about it. Those who don’t, won’t.

Finally back where I want to be...

rgillen — Tue, 27 May 2008 01:53:39 GMT

It's frustrating to me to find myself redoing things that I've done before or re-solving problems. Over the years at Planet I've been involved with different software teams each with different levels of rigor, however most all of them have had, at minimum, an automated build process of some sort (at least for the past 4 years or so). Some of these systems were elaborate msbuild driven systems while others were a cobbling together of batch scripts or PowerShell linking msbuild, Vault, FogBugz and Community server.

The customer I've been working with for the past 16 months has "bitten off" the entire TFS tree and I've been the prime developer responsible for implementing it and getting it going... all, of course, while doing "real work". Further, (nearly) all of the work we've been doing has been SharePoint focused (custom list event handlers, web parts, site definitions, etc) which means any build must generate properly formed SharePoint Solution (*.wsp) files and the approaches to doing this and handling the installation/upgrade of such are pretty varied.

This weekend I finally completed a build on a project that meets my "minimum requirements" for being a properly formed build. I'm pleased that I was able to, in relatively short order, apply it to another project verifying repeatability. Here's what we're doing:

All build scripts are handled by TFS 2008 (using OOTB functionality)
Solution manifest files and DDF files are maintained both in dev and production build by a customized version of stsdev v1.3 (http://codeplex.com/stsdev)
An "installer" is provided as part of the build (<buildRoot>/Install) that allows the back office team to simply double-click and go. We use the SharePoint Installer (http://codeplex.com/sharepointinstaller) tool/framework to provide this function
All required web.config settings are handled via the feature receiver allowing them to be properly installed/removed on activation/deactivation
Developer-level documentation is provided for the build based on the /// comments in the code. We use Sand Castle (http://codeplex.com/sandcastle) to do the core generation and Sand Castle Help File Builder (http://codeplex.com/shfb) to assist with the build script integration (I tried DocProject - http://codeplex.com/docproject - but it pooched vs 2008 and never worked as described - hopefully it will be more stable when it exists beta).
Passed Style Cop (MS Source Analysis) rules
Passed Code Analysis rules

I still have a ways to go prior to reaching my "nirvana"...

Build should automatically run code analysis (this is certainly possible, I've simply not gotten it implemented yet)
Build should automatically run source analysis (this is possible, I've simply not gotten it implemented yet)
Full testing (unit and system) on build completion - Ideally it would spin up a VM, deploy the appropriate code, execute the test battery, clean up and report on the results.

Even so, it felt good to get a respectable build out the door and to know that it was process driven and repeatable.

VS 2005 Project Subtypes

rgillen — Thu, 15 Jun 2006 18:06:00 GMT

I’ve had the opportunity lately to work on a project that needed to generate some code for a project based on a given file within the project and then include/add those files to the project for inclusion during build. We spent a good bit of time looking at the various options such as custom MSBuild tasks, add-ins, VSPackages, etc. and finally settled on a Visual Studio Package that implemented a project subtype, a custom project property page, and a custom tool (single-file generator).

The documentation in the VS 2005 SDK continues to improve as does the general toolset. For those of you who aren’t aware, the SDK team has moved to a very aggressive release schedule posting new builds every few months in the CTP/RTM model. Of particular note has been the improvements to the managed package framework - MPF (no, not Microsoft provisioning framework). These improvements have made it possible for non-C++ aficionados such as myself to write some interesting tools fully integrated into the platform.

I used the ProjectSubType sample (installed by default to C:\Program Files\Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Archive\CS_Samples\ProjectSubtype\ProjectSubtype) provided in the SDK as my guide for much of the features I needed to implement. I encountered a few “gotchas” along the way (thanks to those who lent support) and I am going to document them here for my own sake (easy to find in the future) as well as maybe helping others who find themselves hitting the same issues. In this post I’ll cover a few of the items I hit and I’ll cover some others in subsequent posts.

Creating a project sub-type seemed incredibly easy… simply modify/include the files I wanted in a /templates/projects directory (this really can be anywhere so long as the path is properly registered for your package in the registry) and I was ready to go. The SDK documentation is really pretty clear on this and you will find yourself with a custom project (in my case a flavor of a C# class library) in no time at all.

The first place where things got a little hairy was the custom properties page. I actually took the samples from the ProjectSubType project and had a custom page in no time, however it had one major drawback as it related to my project – the properties it saved were configuration specific (i.e. debug/release) rather than being configuration ambivalent as I wanted. I spent some time fighting through things and finally ended up doing the following…

On my project sub-type (project.cs) I implemented the IPersistXMLFragment interface nearly identically from the SDK sample documents. The only thing I did differently is that I did not pass the request on to other project sub-types (I don’t intend for anyone to sub-type my project).
I created an interface (say IMyCustomProperties) that defined accessors for the properties I wanted to expose and then implemented the interface on my flavored project (project.cs).
The default sample shows (in the implementation of IVsHierarchy) the GetProperty method removing one property page and then adding another. What I learned, is that the case branch in which they remove a property page (__VSHPROPID2.VSHPROPID_PropertyPagesCLSIDList) is actually where you want to add your page if you want it to appear and be configuration independent. As in the following…

protected override int GetProperty(uint itemId, int propId, out object property)

{

switch (propId)

{

case (int)__VSHPROPID2.VSHPROPID_PropertyPagesCLSIDList:

{

// Get the list from the base class

ErrorHandler.ThrowOnFailure(base.GetProperty(itemId, propId,

out property));

// Add our WES Property Page

Debug.Assert(typeof(IPropertyPage).IsAssignableFrom(

typeof(MyPropertyPage)),

"Property page should implement IPropertyPage");

property += ';' + typeof(MyPropertyPage).GUID.ToString("B");

//property = propertyPagesList;

return VSConstants.S_OK;

}

return base.GetProperty(itemId, propId, out property);

}

Where MyPropertyPage is a local class that inherits from PropertyPageBase.PropertyPage (provided as shared-source in the SDK).

The item I struggled with for quite some time was the implementation of MyPropertyStore – a class for interacting with the data store and implementing PropertyPageBase.IPropertyStore. The sample project implements this file, however it is once again interacting with configuration-specific data and the way in which it retrieves the main “data object” (casting the data object in the Initialize() method as IVsCfg). NOTE: The Initialize() method is called by the SetDataObjects() method that is implemented in the PropertyPageBase.PropertyPage class. I knew that what I really wanted was to get the IMyCustomProperties interface from my project object so I could access my custom properties. I tried a QueryInterface on the data variable using all sorts of classes and interfaces and was patently unsuccessful until someone pointed me in the correct path… the proper procedure when using project-based properties is to cast the object as an IVsBrowseObject first, and then you can call GetProjectItem to retrieve the IVsHierarchy object, from which you can finally obtain the custom interface you wanted…

void PropertyPageBase.IPropertyStore.Initialize(object[] dataObject)

{

// If we are editing multiple configuration at once, we may get multiple objects

foreach (object data in dataObject)

{

if (data is IVsBrowseObject)

{

// get the Browse object...

IVsBrowseObject browse = data as IVsBrowseObject;

// Get the project item...

IVsHierarchy project;

uint count;

browse.GetProjectItem(out project, out count);

// now get/store the IMyCustomProperties object

this.myCustomProperties = (IMyCustomProperties)project;

}

else

{

Debug.WriteLine("Not IVsBrowseObject");

}

This was the trick that allowed me to finish my implementation of the custom properties page, and to have data read from the .csproj file, displayed in a custom properties tab, edited by the user, and then persisted to the .csproj file.

I’ll eventually post a full sample, but in a follow-up post I’ll illustrate how I was able to read these properties in my custom single file generator.

This posting is provided "AS IS" with no warranties, and confers no rightsPosted from Word 2007

MPS SDK Part 2 of ?

rgillen — Mon, 05 Jun 2006 14:00:00 GMT

I am preparing to give a talk/introduction to the MPS SDK at the end of this week based on the outline below. I thought I'd list some of the thoughts/comments here under each of the points as a general resource for anyone interested. In this post, I'll list my outline and then expand on the first points with subsequent posts expanding on the remaining points.

Introduction to the SDK (scope, purpose, supported platforms, etc.)
Installation (prerequsites, potential "gotchas", etc.)
VS 2005 SDK Overview
Item templates
Provider Templates/Wizard/BaseClass/Intro to sample providers
Intellisense (& XSLT Extensions)
MPS SDK Options panel
Introduction to the Named Procedure Browser
Introduction to the Procedure Step Browser window & the Content Window
Introduction to the Find All Procedure References window
Code-window context menus
Solution Explorer context menus
Future plans/goals

1. Introduction to the SDK (scope, purpose, supported platforms, etc.)
My previous post on this topic (as well as one written by Conrad or by Mike) covers a good bit of the introductory-style information for the SDK. Essentially the goal is to provide MPS developers (product team, ISVs and ISP in-house developers) a set of tools to ease the task of building applications that consume as well as extend the Microsoft Provisioning System. This has been a long-time gripe of every developer I've spoken with - the platform is interesting but seems "klugy" to work with. There is no debugger, no designer, and no real developer guidance. Thankfully that (well... some of it) is about to change.

The SDK is being made available as part of the on-going solution set Microsoft has been providing for the Hosted Exchange, Windows-based Hosting and now ISV customers. A beta is now available and, while much has changed between the beta and the final version, the current drop should give you a good idea of what the final product will do.

The primary target platform is Visual Studio 2005 and the .NET Framework v2 although there is some support for Visual Studio 2003 and the .NET Framework v1.1. The toolset includes most everything you need to build solutions based on MPS including templates, provider wizards, intellisense, samples, integrated help (coming soon) and other tools. The SDK does not currently include a namespace debugger (you can still use TraceView) or a visual designer for building named procedures, but it does include some tools that provide great assistance to the namespace developer including drag-and-drop calling of procedures, integrated procedure "dis-assembler", sample generator, and context menu-based "execution" of procedures saving you the time of having to look up the documentation and hand-craft the Xml request just to test a simple call.

2. Installation (prerequsites, potential "gotchas", etc.)
A normal installation machine would be a developer box running Windows Server 2003 SP1 or greater, have either Visual Studio 2003 or Visual Studio 2005 (preferred) and the MPS client installed. Depending on which version of Visual Studio is installed, the appropriate components for that version will be deployed (you can have both installed and all components/samples will be installed).

One thing to note is that if you are installing the Visual Studio 2005 version, you should ensure that you have run Visual Studio at least once prior to installing the tools... this allows the SDK installer to read the registry keys necessary to properly locate/deploy the support files.

For Visual Studio 2005, the project templates are currently deployed *per user* rather than for all users... if you need the templates available for other users you will need to copy the zip files from C:\Documents and Settings\<your alias>\My Documents\Visual Studio 2005\Templates\ProjectTemplates\<language>\Microsoft Provisioning System to the same location under their "My Documents" folder.

For Visual Studio 2005, the add-in registration file is currently deployed *per user* rather than for all users... if you need the add-in available for other users you will need to copy the file named Microsoft.Provisioning.Sdk.Addin from C:\Documents and Settings\<your alias>\My Documents\Visual Studio 2005\Addins to the same location under their "My Documents" folder.

If the MPS client is not installed and/or the machine is not a member of a valid (read: "working") MPS environment/domain, many of the integrated tools will not function properly... if you have troubles, make sure you can perform "normal" MPS operations from the box outside of the VS environment.

This posting is provided "AS IS" with no warranties, and confers no rights

New SDK for the Microsoft Provisioning System!

rgillen — Fri, 26 May 2006 11:57:00 GMT

I’ve recently recieved clearance to discuss a project I’ve been working on for quite awhile – a new SDK for the Microsoft Provisioning System. This is something that has been a goal of mine for a number of years, and if you have done any significant development for/with MPS you will be glad to hear that the developer toolset is finally going to be shipping (no, don’t ask me when – but it shouldn’t be too long).

There are a number of things still missing from the SDK (things we wanted to include but were simply unable to for time or other reasons) but I’m very pleased with the feature set and feel that this will provide a great step forward for MPS developers. In future posts, I’ll dive a bit deeper into the various feature sets, but in this post I figured I’d simply provide an overview of the toolset.

Support for Visual Studio 2003 - in general, the support for VS2K3 is not as extensive as with VS2005 - users of this development platform will have access to a project template for building C# providers, Intellisense for authoring MPS Namespaces and Requests, and some general template files.

Support for Visual Studio 2005 – Because of the improvements that the Visual Studio team has made to the extensibility model in VS2K5, we were able to integrate a number of features into this platform very easily. The VS2005 edtion of the SDK is a superset of the 2K3 SDK adding an updated provider base platform (more on this later), support for VB.NET providers (and other .NET languages – I’ve personally tested C++.NET and J# – although project templates are only provided for C# and VB.NET), integrated namespace/procedure browser, procedure dissassember, context menus allowing the user to submit requests and register namespaces directly from the VS code window, the ability to generate samples for methods, drag-and-drop support for quickly building namespaces, sample providers, integrated help, and much more.

This posting is provided "AS IS" with no warranties, and confers no rights

Using XSD in your C# and MPS programming...

rgillen — Sat, 14 Jan 2006 14:08:00 GMT

So I need to begin this post by admitting that I’m relatively new to the XSD world… particuarly as it applies to C#. While I’ve done a signficant amount of Xml programming and manipulation in C#, my recent forrays into this technology cause me to reconsider my belief that I’m an experienced Xml programmer…

Lately I’ve been working both with team members at my company as well as some colleagues from other companies on the topic of better and/or more consistent processing of the Xml used to passs data in and out of the MPF engine. It seems that we all tend to be very comfortable working in an OO C# environment both at the layer above MPF (presentation/application layer, etc.) as well as below the engine (providers). It seems that we are frequently performing the same operations (getting Xml nodes, performing validation steps, adding nodes to Xml documents, etc.)… one would think that there could be some more consistent/resuable fashion… and we did… various libraries of different sorts that we reused and extended on both sides of the engine.

I’ve been playing with an idea suggested to me by Mark which is to use XSD schemas to define the Xml “interfaces” and then, utilizing xsd.exe, generating C# serializable classes to represent those Xml blobs. Then I can utilize the serialization and de-serialization tools built into the .NET Framework to convert the C# objects into the input Xml stream as well as to deserialize the return back into object form for normal processing. Further, I can use the new validation features of a .NET 2.0 XmlTextReader (as compared to a 1.1 XmlValidatingReader) in conjunction with the Xsd file used to generate the class to validate Xml input from external sources.

For the most part, this approach is very interesting to me and I’ve been using it on a project recently and been increasingly pleased. There are, however, a few things that I’m not completely pleased with… some of which I’ve found work-arounds for and others that are still open issues.

Documentation – One of the issues I ran into was a relative lack of documentation and online material on this topic (found plenty of Xsd information in the context of DataSets, but not much in the way of custom serialization and Xsd definitions which is why I’m writing this blog post (maybe it will be helpful to someone else looking for information on the topic). I should note that I did find a fair amount of information on Xsd integration and utilization but very few articles that discuss any .NET 2.0–specific features/issues.
Auto Generation of Code – I was really hoping for some “magic” switch or property I could set on each of the Xsd files in VS.NET that would cause VS.NET to automatically generate the C# from the Xsd for me (maybe at compile time?) however, no such switch is to be found (at least not yet by me). Instead, I’ve been generating the XSD’s and then shelling out to a command prompt to use the xsd.exe command line tool.
Inability to “Decorate” XSD – I have actually found work-arounds to the items below, however they involve manipulating the generated C# rather than modifying my XSD in some way to control the code generated by the output. While my current approach works, it leaves me open to problems if/when I need to regenerate my C# due to updates to my XSD.
Casing – Another problem I ran into was that xsd.exe uses the element and attribute names from the schema to generate the names for the C# objects and properties. The *problem* with this is that most of my Xml nodes are camel-cased which results in C# class names that are camel-cased. This is inconsistent with our internal coding standards (as well as FXCop rules) which require them to be pascal-cased.
Naming – for similar reasons as the previous item, my generated C# classes ended up with some pretty interesting names such as classes called keykey or keypropertytype. Probably more than the casing, it was important to me to “fix” this problem so that the resultant code was legible for the next person working on this codebase.
Arrays vs. List<t> – Further complicating things is the fact that xsd.exe generates C# that uses strongly-typed arrays for collections of nodes. While these definitely work, they seem “klugy” to me as I’ve gotten rather used to Add() method of the ArrayList. Further, I’ve lately become very comfortably with strongly-typed lists (List<t>) in .NET 2.0 and really would prefer to use that programming construct instead.

I was able to work around the casing issue for switches by modifying the generated C# classes to match our coding standards and then decorating them so that the XmlSerializer knows which Xml nodes to algin with which classes. The xsd.exe tool initially genrated code that looked like the following:

[System.Xml.Serialization.XmlElement()]
public key key
{
    get { return this.keyField; }
    set { this.keyField = value; }
}

I then updated the code and tweaked the decoration as follows to ge the casing the way I wanted…

[System.Xml.Serialization.XmlElement("key")]
public Key Key
{
    get { return this.keyField; }
    set { this.keyField = value; }
}

What stumped me for a few minutes was how to handle the casing of the parent node of a collection (i.e. a node named keys that has children named key). The compiler generated code that looks like

[System.Xml.Serialization.XmlArrayItemAttribute(IsNullable = false)]
public key[] keys
{
    get { return this.keysField; }
    set { this.keysField = value; }
}

What I wanted, is a property called Keys (rather than keys). There were two tricks I found here. The first was to indicate the naming of the child nodes (“key”) which is accomplished by setting the ElementName property of the XmlArrayItemAttribute as follows:

[System.Xml.Serialization.XmlArrayItemAttribute(ElementName = "key", IsNullable = false)]

The second step, is to decorate the property such that the the serializer knows that the Key[] array maps to the <keys/> node. This is accomplished by adding an additional decoration to the property of type XmlArray() and setting the constructor value. The following is the fully updated (at this stage) array property.

[System.Xml.Serialization.XmlArray("keys")]
[System.Xml.Serialization.XmlArrayItemAttribute(ElementName = "key", IsNullable = false)]
public Keys[] Keys
{
    get { return this.keysField; }
    set { this.keysField = value; }
}

Next I set to work on the array issue… I really wanted to be using strongly-typed lists (List<t>) which I figured had to be possible. Come to find out, it is, and all you have to do is change the types (no futher decoration necessary) yeilding an updated signature as follows:

[System.Xml.Serialization.XmlArray("keys")]
[System.Xml.Serialization.XmlArrayItemAttribute(ElementName = "key", IsNullable = false)]
public List<Key> Keys
{
    get { return this.keysField; }
    set { this.keysField = value; }
}

Finally, I wanted to address the naming issue… Looking at the steps I’d accomplished so far, I figured that the decorations simply allow me to disassociate the C# class/property name from the Xml tag name and it proved to be correct – in the same way that I was able to adjust for casing, I could adjust for naming changes.

At this point I had solved most of my problems so I continued working and will use it “as-is” for the time being… if only I could have decorated the XSD so that these changes would be implemented as the code was generated…

Writing MPF Schemas is easier now using VS 2005

rgillen — Tue, 19 Jul 2005 16:28:00 GMT

I know many people do not take the time to include schemas in their MPF named procedures, but I am a big fan. Here at eQuest, we use these in-line schemas for all sorts of things ranging from auto-generating CHM files to auto-generating strongly-typed C# and XML Web Service wrappers. The problem is, these are a *pain* to write. I hate writing them, and even worse, they are hard to get accurate. It is very easy to miss a step, or mis-state a requirement, etc. It is very easy to duplicate a node, or forget to include a node, etc.

Yesterday I was faced with the need to write a schema for a named procedure I had just written for a client. Because of some rather unique lab environment issues, I elected to write them directly on my machine, where, I just happened to have VS.NET 2005 Beta 2 installed.

What I found was that VS.NET 2005 includes two features that make the editing of XML and the associated schemas much easier. The first is intellisense. This is not a surprise, and I had heard that VS 2005 included better support for a wider range of XML namespaces, but I suppose I didn’t really think about it until it “just started working”. The following is an example of in-line schema intellisense…

The second feature, and probably cooler feature (from my perspective) is the ability for VS to validate the schema nodes I’m creating relative to the schema nodes I’ve already created. For example, if I add an <element /> node for a type for which I have not yet defined an <ElementType/>, I will get the appropriate squiggly lines indicating a problem. The same is true for <attribute/> and <AttributeType/> tags. Also, if I have duplicate <element/> nodes it will complain. Where this helps me, is that it is often easier (for me, in my limited view of this) to begin by creating the <ElementType /> node for type=executeData and then populating all of the appropriate <element/> nodes. Then, I can use the validation features of VS to let me know when I have finished implementing the required <ElementType/> nodes. The following is a screen shot of this validation:

These are great new features and I’m excited to see how this will speed my development moving forward

(note: yes, I’m aware that XMLSpy does this now, but I’ve simply not been able to get myself into the habit of having two “heavier” apps running to support my coding… I end up using VS for all of it… and I’m also aware that XMLSpy has an add-in for VS… but it changes the XML fonts and styles and that bugs me… oh well…)