Here are some previous posts which (briefly) describe the domain:

http://blogs.rev-net.com/ddewinter/2008/02/16/the-linq-to-sql-model/

http://blogs.rev-net.com/ddewinter/2008/02/16/linq-to-sql-and-database-schema-sync/

Any ideas about directions for the tool? Or maybe something that wasn’t covered in the screencast? I’d love to hear your ideas.

If you remember from last time, we were able to create a dynamic menu command without any lines of procedural code (other than those generated by the wizard). The result was a menu command that showed itself only when no solution was loaded in Visual Studio. Immediately a solution was loaded, the menu command disappeared. The limitations of this approach are that you’re reliant on built-in UI contexts, such as UICONTEXT_NoSolution. However, what I needed for my DBML Fixup project was a way to add menu commands when right clicking on .dbml files (LINQ to SQL Classes) in the Solution Explorer. The built-in UI contexts that we reviewed in the previous post are not enough to give us this functionality. In this tutorial, I take you through step-by-step on how to add this feature to your VS packages. We have to do a bit of digging though, so let’s get started!

The first thing we need to do is to create a new a menu command using our existing solution. Because we don’t have the wizard to help us this time, we’ll have to create our menu command from scratch.

Step 1: Creating the New Command

Our first step is to create the GUID:ID pair that Visual Studio will use to identify our new menu command. The GUID represents a set of commands (or command set) exposed by this package; one of these was created by the package wizard when the solution was generated. However, for this part of the tutorial, we’ll go ahead and create a new command set in the Guids.cs file. (We can get a new GUID from the Tools > Create GUID menu item.) Afterwards, my Guids.cs file looks like this:

Pardon the unoriginal name of "CmdSetPart2." The next step is to add an ID that maps to the specific menu command we are going to add. This can be changed in the PkgCmdID.cs file in our project. Here I will add the cmdidQueryStatusCommand with a value of 257:

So that was fairly simple, but obviously we haven’t registered it with Visual Studio, so there’s no way the Visual Studio shell will know about this menu command. To do so, we need to make some amendments to the .vsct file. The first of these changes is to identify the new menu command GUID and ID pair in the Symbols section, so that we can reference it elsewhere. This is also easy to do and requires a few lines of XML, which can be added as any first-level child of the Symbols node:

As you can see, this information is based directly off the two previous steps. The "guidDynamicMenuDevelopmentCmdSetPart2" command set has the same GUID as in our GuidList class, and the "cmdidQueryStatus" menu command ID has the same value as in the PkgCmdIDList class.

Our objective is to show this menu command when we right click on DBML files in the designer; this means we’ll need to create a new Group element whose parent is the Solution Explorer’s context menu. Then we’ll need to create a Button element to put in that Group, which represents the menu command itself. This doesn’t seem like such a problem, until you try to define the Group’s parent…

What goes in the place of the question marks? Well, we might be able to find it in one of the copious header files that sits in the Visual Studio SDK’s VisualStudioIntegration\Common\Inc directory, but I’m willing to bet that there’s a faster way. And it turns out there is. Looking at Dr. eX’s blog entry on VSIPLogging reveals that a simple registry key will allow you see to the GUID:ID pair of almost any menu command in Visual Studio, including those developed by third parties. Changing this setting in the registry and relaunching Visual Studio allows us to check what the GUID and the ID we need are; as it turns out, holding the Ctrl+Shift keys down and right clicking on a project item in the Solution Explorer gives us the information we need:

We can use this information to fill in the Parent’s details, but we’ll need to register the GUID and CmdID in the GuidSymbols element in our .vsct file first.

The Button element isn’t too exciting by comparison; in fact it doesn’t differ much from the Button element from the last tutorial. I include it here for reference:

OK, that’s it for the .vsct edits. Notice that our Button element still has the "DynamicVisibility" flag, but we have not specified a visibility constraint; this is because we will handle the changes ourselves in procedural code. The final thing we have to do to finish the "plumbing" work by creating our menu command and an event handler to handle its invocation. I’ll add this code in the DynamicMenuDevelopmentPackage.cs file in the Initialize method. If you navigate there, you’ll see the wizard-generated code for the first menu command. It’s only a few lines of code to hook everything together with our second menu command:

One thing to note here is that in contrast to the first menu command, we are creating an OleMenuCommand, not a regular MenuCommand. The reasons will become apparent later, but for now, let’s press F5 to see what we’ve got. Open an existing solution (or create a new one if it’s easier to do so) and right click on a project item (not a folder, project, or solution node, though) and you will see our "Query Status" command:

Step 2: Making It Dynamic

As expected, though, it shows up regardless of the selected item in the project, so we haven’t reached the end yet! Going back to the code in DynamicMenuDevelopmentPackage, we discover a use for the OleMenuCommand vs. the MenuCommand. The OleMenuCommand exposes an event called BeforeQueryStatus, which is raised right before Visual Studio asks what the state of a particular menu item is. In this case, it’s a perfect place to edit the state of our menu command based on the current selection in the Solution Explorer. Adding the following event handler to the BeforeQueryStatus event of that OleMenuCommand helps us achieve our desired goal:

I won’t explain all the code here, but the gist is that we are getting the name of the current selection, checking if it ends with the ".dbml" extension, and dynamically setting the visibility on our menu command based on that result. Unfortunately, this is still not enough to correctly implement our dynamic menu command, due to the fact that Visual Studio loads packages on demand. To make a long story short, the code that we just wrote to handle dynamic menu item visibility will be called only when the package is loaded, and the package is loaded only when some UI element exposed by the package is clicked, which invokes some piece of code in the underlying package. This does not really help us when all the package exposes is two menu commands!

This is a problem that I encountered recently, and consequently I am open to any suggestions. My solution has been to put the ProvideAutoLoadAttribute on the class, which tells Visual Studio to load the package automatically when it encounters a certain UI context. In this circumstance, the context "UICONTEXT_SolutionExists" (defined in vsshlids.h) suits our purposes perfectly. We’ll have to specify the GUID itself instead of its alias, however, like this:

And that’s it! Press F5 and open a solution to see for yourself. The "Query Status" command will appear only when right-clicking on .dbml files in the Solution Explorer.

Associated Solution

Other Articles in the Series

• Part 1 – Using UI Contexts
• Part 3 – Custom UI Contexts

In this series of posts I’m going to focus on three ways to make menu commands dynamic—that is, how to make menu commands invisible or disabled in certain contexts, but visible and enabled in others. Two of these ways I found through some experimentation. Consequently, I’m not sure whether these represent VSX best practices, so if anyone has any more input, it would be greatly appreciated. With that said, let’s get started.

Using a Built-In UI Context

For each of these techniques, I’ll be using the same solution, and I’ll post the solution with the current progress at the end of each post. But…first things first: create a new project and select the Visual Studio Integration Package project type.

The Visual Studio Integration Package Wizard pops up. For this tutorial we’ll use Visual C# and generate a new key file to sign the assembly.

For the basic information page, feel free to type whatever you want for the company name, package name, and detailed information. I’ll leave the minimum Visual Studio edition at "Standard," as well. On the next page, check the Menu Command check box to indicate to the wizard that we want to, of course, make a menu command.

We’ll provide the following command name and ID for the command the wizard will generate:

On the last page, uncheck the Integration Test Project and Unit Test Project options, as we won’t need these for this demonstration. If you are interested in the Integration Test and Unit Test options, have a look at this blog entry. Click "Finish," and the wizard will create the majority of the solution for us. Press F5 and verify that a "Built In UI Context" menu item appears in the Tools menu:

The integration package wizard has gotten us this far, but we have to supply the finishing touches in order to make this menu item dynamic. In order to do this we need a little background in the .vsct file’s structure. There should be one in your project (DynamicMenuDevelopment.vsct in my case). Go ahead and open that file. The following will briefly touch on the different points of the .vsct file. If you don’t have any previous experience working with these, please read this excellent post before continuing.

In the VSCT file, our menu command is represented by the sole Button element:

That "button" is parented by the "MyMenuGroup" group element:

And that group is parented by the Tools menu. If we look at the GuidSymbols element in the file, we can see the GUIDs for our package, guidDynamicMenuDevelopmentPkg, as well as our set of commands, guidDynamicMenuDevelopmentCmdSet. The latter has some IDs which identify the single menu command and the group: cmdidBuiltInUIContext and MyMenuGroup, respectively. But if you look at the Group’s parent in the previous XML snippet, you’ll see a GUID guidSHLMainMenu and an ID IDM_VS_MENU_TOOLS which are not defined here. Where do they come from? They are defined externally in the vsshlids.h, which we "imported" using one of the Extern elements at the beginning of the document.

From here, it’s very simple to add dynamic visibility. Navigate back to the Button element and add the CommandFlag element, as demonstrated below:

Simple, right? We’ve told Visual Studio that this command may be invisible at times and visible at other times, but we haven’t told it when. To do that, we must add a VisibilityConstraints element underneath the closing Commands tag.

If you think about it, you can make some educated guesses about what this piece of the XML says. The VisibilityItem element specifies the same GUID and ID pair as our Button element above, so they must be related. Furthermore, the element specifies a context attribute which we have not seen before. This is the sole part of the VSCT file that tells Visual Studio when a particular command is visible or invisible. You can also infer that UICONTEXT_NoSolution means that the menu command will be visible only when there is no solution open. Press F5 and try it!

That leaves one last question before wrapping up this technique, and that is "Where is UICONTEXT_NoSolution defined?" It certainly isn’t in our GuidSymbols, but if you remember we have a couple of external header files that we reference. One of those is vsshlids.h. If you navigate to the %PROGRAMFILES%\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Common\Inc directory, you’ll find vsshlids.h among a multitude of other header files. If you open that file and search for "UICONTEXT_", you’ll see a couple of different contexts, including UICONTEXT_NoSolution. You can use any of the other UI Contexts in this file in order to control dynamic visibility for your menu command.

That was pretty good for writing only a few lines of XML, but if there’s no built-in UI context that fits your requirements, then this solution will not work for you. Also, this technique works only for hiding and show menu commands, not for disabling and enabling them. In short, while it’s fairly easy to do, it’s sometimes not flexible enough for the job.

Next time I’ll outline another technique, which is also fairly simple, but requires us to write some code. Hope this helps you in your VSX development!

Edit: I realize I forgot to post the solution for this example! It is a Visual Studio 2008 solution and it’s located here.

Other Articles in the Series

• Part 2 – The BeforeQueryStatus Event
• Part 3 – Custom UI Contexts

At first I tried to dissect LINQ to SQL by keeping track of the various elements and attributes and their representations in the XML and the designer in big Excel tables. They quickly became unwieldy, and I decided to cut my losses and model the LINQ to SQL schema (DBMLSchema.xsd). Needless to say this was a very challenging exercise, but I gleaned a significant amount of knowledge about LINQ to SQL after finishing it.

The purpose of this post is to post the various pages of the LINQ to SQL model; I want this post to clarify the infrastructure of LINQ to SQL to others, so I would appreciate if you can comment on any inconsistencies or missing constraints you can see. I used Object-Role Modeling (ORM) for the model, so if you are not familiar with that, you may want to check out the following resources:

1. Object Role Modeling: An Overview, http://msdn2.microsoft.com/en-us/library/aa290383(VS.71).aspx
2. Halpin, T. 2001. Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design.San Francisco: Morgan Kaufmann Publishers

The model starts like this…here’s the database page. The derivation rules aren’t on the diagram explicitly, as they are stored as part of the properties of the fact type. Other advantages of having the .orm file are that I’ve put definitions on all of the fact types to clarify their meaning, in the case that the predicate text is still not clear enough. If anyone wants the .orm file, feel free to contact me at david.dewinter AT (@) rev-net DOT (.) com. (You can open .orm files with Visual Studio after installing Project NORMA.) I will also put up a contact form soon…

Figure 1. The Database element.

Figure 2. The Connection element (renamed ConnectionDetails for clarity).

Figure 3. The Table and Type elements.

Figure 4. The Column element.

Figure 5. The Assocation element (renamed AssocationEnd for clarity).

Function 6. The Function element.

Figure 7. The TableFunction element.

How do I keep my generated entity classes in sync with the current database schema using LINQ to SQL?

For some people, this question is moot. It’s easy enough to utilize the current “resync” mechanism in LINQ to SQL by deleting all the entity classes and functions (the LINQ to SQL term for sprocs and UDFs) on the designer surface and then redragging and dropping the tables and functions of interest, thus updating the entity classes by regenerating from scratch. However, for others, this solution is not good enough for a few reasons:

1. In the organizations I’ve been in, column names are camel case, and .NET property names are Pascal case. When creating the entity classes, I have to fix the casing of all the properties since their names default to the names of the columns. Using the solution above, I would have to repeat this process every time the database schema changed!
2. If developers prefix their table and column names with “tbl_”, “int_”, “str_”, “usp_”, etc. but have different standards in .NET code, then they have to change the generated entity class and property names every time the database schema changes.
3. There are quite a few properties that a developer can set in the .dbml (LINQ to SQL) file that cannot be set in the designer. Every time one of those properties is set, it exposes a risk in that they have to be reset every time the database object on which that property was set changes.
4. Not even considering name changes (which are understandably trivial to some people), what about inheritance relationships? The designer can’t infer when a table maps to a class hierarchy (table-per-hierarchy, or TPH). Every inheritance relationship has to be remapped when the database is changed.

And the list goes on…

As you can see, all of these customizations can become quite expensive over time if a database changes often. Perhaps some developers have taken it upon themselves to write their own scripts to keep their customizations in the .dbml file for a single database, which is great, but not scalable. I believe something that the community could benefit greatly from is a tool that tracks customizations to the file and allows them to restored after the designer re-generates the entity classes and functions. Perhaps something that could manage the entire resync process for you would be even better.

At this point I am fishing for requirements, more specifically common tweaks that developers want to make to the LINQ to SQL files. The common tweaks I have identified so far are (1) to transform property names to be Pascal case, (2) to remove prefixes from the names of database objects, and (3) to automate mapping the types of columns to various (developer-defined) enumerations.

Any input you guys can give would be appreciated! I’ll be posting more on this tool in the future. Currently its name is “DBML Fixup,” but if you have any better alternatives feel free to share.