We all have utility methods that just work. But if you're in Debug mode and stepping through your code (and you forget to shift from using F10 to F11), you end up having to step through your utility method.
Of course, once you're in the method, you can use F7 to step out of the method and onto the statement following the statement that called your utility method. But it would be much better to just not step into the method at all.
That's easily done: just add the System.Diagnostics.DebuggerStepThrough attribute to your method. The next time you're stepping through your code, Visual Studio will just step over your method. Just remember to take the attribute off if you want to put a breakpoint in your utility method: Visual Studio takes this attribute very seriously and ignores breakpoints inside methods decorated with DebuggerStepThrough.
Posted by Peter Vogel on 01/31/2013 at 1:16 PM1 comments
You've just deleted an item in Solution Explorer and realized that you still needed it. Or, after mucking with some code for several days, you've realized that the original version was the right answer. If you've got source control in place, you can use it to get out of the hole you've dug yourself into. Or, you can just get the file back with Visual Studio, if you're running on Windows Vista or Windows 7.
This is actually a Windows Vista/Windows 7 feature (in everything higher than the Home version). but Visual Studio takes advantage of it. If you pick Open Project, for instance, the Open button in the resulting dialog will have a down arrow beside. Clicking that arrow offers a new choice: Show Previous Versions. Selecting that choice changes the file list displayed in the dialog to show the previous versions of the files in the folder, organized by date. You can then grab the previous version of your project and get your file.
Posted by Peter Vogel on 01/29/2013 at 1:16 PM2 comments
In an earlier set of articles, I showed how to use Microsoft's Fakes Framework and complained about how Fakes is only available in the Ultimate version of Visual Studio 2012. And that's true; but for Visual Studio 2010, Microsoft also has the Moles Isolation Framework for .NET. Moles is similar to shims in the Fakes Framework but, unfortunately, won't see any future development (it's been replaced with Fakes). Still, Moles does work and you can use it for free, even for commercial projects.
But Microsoft has a related tool for addressing a different problem: missing tests. As developers, we tend to test code to make sure it works -- we feed in the results we wrote the code to handle. So Microsoft has a companion to Moles and Fakes called Pex. Unfortunately, to use Pex you must either be an MSDN subscriber or use Pex under the academic license (i.e., not for commercial use).
Pex is a test generator: aim it at your application and Pex generates test cases for you. Pex does that by examining your code and then generating tests that ensures, among other things, every line gets executed. Pex is particularly interested in generating "edge cases": what happens at the outer limits of the ranges you've built into your code. So, for instance, string variables will be tested with null/Nothing values, zero length strings, escape characters, and strings of punctuation marks.
You need to beware of something here: If your code is accessing database or a Web Service, Pex's tests could take a very long time. If your code is performing updates, you could end up with a lot of "interesting" data in your database (e.g. null/Nothing values, zero length strings, strings of punctuation marks). This is, of course, why Pex comes with Moles or Fakes: you really need to isolate your code from your database before running Pex.
You can download Pex through Visual Studio's Extension Manager. After isolating your code, right-mouse click in the method you want Pex to generate tests for and select Run Pex. Then wait. As it's running, Pex will display a table of the inputs it's feeding to your code and the output from each test, including any exceptions. The Pex Explorer window gives you a TreeView of the test results that complements the table view.
Once Pex is finished beating up on your code (Microsoft refers to this as "Pex Explorations"), you can review the results. You can, with a mouse click, save any one or all of Pex's tests as a Visual Studio test; if a test generates an exception, have the generated test accept that exception as an expected result of the test. Alternatively, for any test, you can have Pex write a pre-condition into your code (Pex adds code to your method that tests for that input and throws an exception if it turns up).
If you want to make sure that all the conditions that you wouldn't normally think of are applied to your code (and are an MSDN subscriber or a non-commercial developer), you should take Pex out for a spin.
Posted by Peter Vogel on 01/22/2013 at 1:16 PM0 comments
I don't spend a lot of time interacting with dynamic languages like Python, but I think that I've finally found a use for the dynamic keyword in C#. It's something that C++ developers call "multiple dispatch" (or so I'm told).
Normally, if you call a method that that has two overloaded versions, the choice between the two overloads is made at compile time, based on how the parameters passed to the method are declared. But, by using the dynamic keyword, you can defer the choice between the two methods until run time and have the choice based on the datatype of the data in the parameters, instead of on the way the parameters are declared.
For instance, assume two classes: one called BaseCustomer and another called PremiumCustomer that inherits from BaseCustomer. Also assume a method with two overloaded versions: one version that accepts a Customer object and one that accepts a PremiumCustomer object. Here are the two methods:
public void ProcessCustomer(Customer cust)
public void ProcessCustomer(PremiumCustomer cust)
Now, here's some code that calls the two versions of the ProcessCustomer method. Guess which version is called each time:
Customer cst = new Customer();
PremiumCustomer pcst = new PremiumCustomer();
You probably guessed that the first two lines of code will call the first version of the ProcessCustomer method -- the one that accepts a Customer object parameter. After all, the cst variable passed to the method is declared as Customer and is referencing a Customer object. And, just as probably, you guessed that the second two lines of code will call the second version of the method that accepts a PremiumCustomer. You'd be right both times.
But how about the following example, which declares the variable passed to the ProcessCustomer method as Customer, but holds a reference to a PremiumCustomer? What's your guess for this code:
Customer cst = new PremiumCustomer();
If you guessed that this example still calls the first version of the ProcessCustomer method, you'd be right. That's because the decision on which overloaded version to call is made at compile time, based on the datatype of the variable being passed (and the cst variable is declared as Customer).
You might prefer, however, to have the decision made at run time based on the datatype of the object actually being passed. In other words, in that last set of code you might prefer to have the second version of the ProcessCustomer method called because the cst variable is referencing a PremiumCustomer object. You can do that by casting the parameter using the dynamic keyword, as in this example:
Customer cst = new PremiumCustomer();
This code will call the second version of the ProcessCustomer method because, even though the cst parameter is still declared as Customer, the variable is pointing at a PremiumCustomer object. I won't always want that behavior, but there will be times when this technique is going to be very useful.
Posted by Peter Vogel on 01/10/2013 at 1:16 PM5 comments
Given the number of default interfaces that SharePoint provides, it's conceivable that you might want to create a provider WebPart that several consumers could connect to simultaneously. To make that happen, you must specify in the connection method that multiple consumers are allowed.
After decorating your connection method with the ConnectionProvider attribute, set the attribute's AllowsMultipleConnections property to True. Here's an example of a connection method for a provider that supports the IWebPartTable interface:
<ConnectionProvider("First Name", _
Public Function MyProviderMethod() As IMyWebPartTable
A provider with a ConnectionProvider method like this could drive several consumer WebParts on the same page. You can also mark a ConnectionConsumer as allowing multiple connections which would allow a single consumer to interact with several providers at once (that would, I think, be something of a nightmare).
If you want a consumer WebPart to be able to connect to WebParts that support different interfaces (a consumer WebPart that works with both the IWebPartRow and IWebPartTable interfaces, for instance) then you need two separate connection methods: one for each interface. The same is true if you want to create provider that provides data through two or more interfaces (both the IWebPartRow and IWebPartParameters interfaces, for instance).
When you have multiple connection methods in the same WebPart, you must assign each method a unique id as the second parameter to the method's Connection* attribute. That's what this example does, creating a consumer that can work with both the IWebPartTable and IWebPartRow interfaces:
<ConnectionConsumer("Employee Data", "AllData")> _
Public Sub MyConsumerMethodForAllData(parm As IWebPartTable)
<ConnectionConsumer("Employee Data", "SelectedRow")> _
Public Sub MyConsumerMethodForSelectedRow(parm As IWebPartRow)
However, there are two scenarios related to these examples that aren't supported: A WebPart cannot connect multiple times to the same WebPart; if you have two WebParts that both support both the IWebPartTable and the IWebPartField interfaces (one as a consumer and one as a provider), they can only be connected once. The user will decide at runtime which interface to use.
Also, users can't connect a provider to a consumer that it's already connected to even if they swap roles. You can't, for instance, connect a WebPart A as a consumer to WebPart B as a provider, then turn around and have WebPart B connect as a consumer to WebPart A as a provider.
Posted by Peter Vogel on 12/10/2012 at 1:16 PM0 comments
So I'm at a client's site and we're discussing adding a new method to an existing class. One of the client's programmers said, "We should put the method in the base class and let all the derived classes inherit it from it" Another programmer said, "I think it would be better to create a new class that inherits from our base class and add the new method to it."
And I said, "Let's not change anything. Let's just create the new method."
I had a couple of reasons for disliking the first two suggestions. First, of course they weren't my suggestions. But beyond that, I didn't want to change the base class because the base class had this neat feature: it worked. I hate making changes to working code—it's just asking for something new to fail. Adding a new derived class would avoid that problem, but creates a new one: developers would have to be told to use the new class in order to get access to the new method. Developers were already using the existing classes and I didn't see any value in making them change.
So I suggested we create an extension method and avoid all those problems. An extension method sits in a separate file from the base class, so the base class is unchanged (though the method would be in the same Class Library project and be distributed as part of the same DLL). An extension method also appears automatically in the IntelliSense dropdown lists for the existing classes, so developers would have it presented to them as part of the classes they were already using.
Creating an extension method is easy. In C#, you add a static class with a static method, with both the class and method declared as public. The method's first parameter specifies the class the method will attach itself to (the parameter has to be flagged with the this keyword).
When the extension method is used from an object, that object is automatically passed to the extension method in that parameter. This ToggleCustomerStatus method, for instance, will appear in the IntelliSense list of any Customer object (or any object that inherits from Customer), toggle the value of the Status property on the Customer object the method is used on, and return the new value:
public static class CustomerCSExtensions
public static bool ToggleCustomerStatus(this Customer cust)
cust.Status = !cust.Status;
To create an extension method in Visual Basic, add a Module, declare it Public, write your function or subroutine, and decorate the method with the extension method. The first method parameter specifies the class to which the method will be added. When the extension method is used from an object, that object is automatically passed to the extension method in that parameter.
This ToggleCustomerStatus method, for instance, will appear in the IntelliSense list of any Customer object (or any object that inherits from Customer) and, unlike my previous example, doesn't return a value:
Public Module CustomerExtensions
Public Sub ToggleCustomerStatus(ByVal cust As Customer)
cust.Status = Not cust.Status
To use the extension method, you need to add an Imports or using statement for the namespace that the extension was declared in. If the extension method is in the same namespace as the object it's attaching itself to, developers using that object will probably already have that namespace in place. After that, using an extension method looks just like using any other method (and it doesn't matter if the class the extension method is being attached to is written in one language and the extension method itself is written in another language). Here's the C# ToggleCustomerStatus method in action in some VB code:
Dim cust As Customer
If cust.ToggleCustomerStatus Then …
And the VB version used from C# code:
While my sample extension method accepts only the single parameter that specifies which class it should attach itself to, an extension method can accept multiple parameters, just like any other method. You can also specify an interface as the first parameter's datatype so that your extension method will attach itself to a variety of objects (provided they all implement that interface). And, most importantly, you don't change any working code.
Posted by Peter Vogel on 12/03/2012 at 1:16 PM2 comments
It's hard to create memory leaks in .NET, but I can do it when developing in SharePoint without even trying very hard. The SharePoint Dispose Check (SPDisposeCheck to its friends) analyzes your code to see if you're following Microsoft's best practices in disposing of SharePoint resources.
SPDisposeCheck is a Visual Studio Add-In that adds a new menu item to your Tools menu. When you select it, SPDisposeCheck pops up a dialog that lets you check which parts of your Solution will be checked. In addition to running an analysis when you want, you can also choose to have your code analyzed as part of building your projects. By default, the results are displayed in the Output Window (you have to set the dropdown list at the top of the Window to SPDispose check). However, you can also choose to have any problems listed as Errors.
PDisposeCheck won't stop you from having memory leaks in SharePoint; but at least when you track a leak down, it won't be something so obvious that you'll feel foolish about it.
Posted by Peter Vogel on 11/29/2012 at 1:16 PM0 comments
Scattered across all the services I've created, I must have 257 methods whose names begin with the word "Get" (e.g., GetCustomerData, GetOrdersForDate). And I typically have a corresponding method for accepting the data (e.g., UpdateCustomerData, SetOrders). I wouldn't write a class like that with two separate methods; I'd create a Property just called, for instance, CustomerData.
It turns out that you can use properties in a WCF Service: just put the OperationContract attributes on the property's getter and setter:
Public Property CustomerData As String
Set(value As String)
_CustData = value
Now, when I add a service reference to a consumer to generate the client-side proxy, I discover that I've only solved half of my problem. For the example above, the client-side proxy has two methods: get_CustomerData and set_CustomerData:
Dim cr As New CustomerService.CustomerServiceClient
Dim custData As CustomerData = sr.get_Data()
But on the service side, I no longer have two separate methods. Instead, the getter and setter for my data are now brought together in one Property. I'm OK with that.
If you're feeling very radical, you can write your property so that it accepts a parameter:
Public Property CustomerData(CustomerID As String) As String
Set(value As String)
_CustData = value
On the client-side, the proxy's get_ and set_ methods will now require a parameter:
Dim cr As New CustomerService.CustomerServiceClient
Dim custData As CustomerData = sr.get_Data("ALFKI")
Posted by Peter Vogel on 11/26/2012 at 1:16 PM0 comments
I'm not sure whether to classify this as a tip or bad advice: It's possible to redefine the operators (e.g. !, =, ++) used with a class. That doesn't mean it's a good idea. As I discussed in an earlier tip, the differences in using equality tests between C# and VB (and, within a language, the differences between the equals operator and the Equals method) probably create enough confusion without you assigning an arbitrary meaning to =/== for a particular class. But having said that…
Let's say you have some class that switches between two states: A Customer class that can be creditworthy or not creditworthy; a Service that switches between being "in" or "out" of service; a Product that is in-stock or out-of-stock. You can have a property that allows you to control this:
Dim cust As New Customer("A123")
cust.Creditworthy = False
To toggle between the two states, you could use this code:
cust.CreditWorthy = Not cust.Creditworthy
But it might be nice to just do this to toggle the Creditworthy property:
cust = Not cust
Before showing how to implement this, let me point out my chief objection: How would anyone reading your code or using your Customer object know what the Not operator is doing?
But if you want to do it, you add a shared/static Operator method to your class with the name Not. This Operator method should accept and return the object that it's part of (if you wanted to redefine the + operator, you'd add an Operator method called +). That method will be passed the object that the operator is being used on so that you can modify the object if you wish. Implementing my state-switching code would look like this:
Public Shared Operator Not(Cust As Customer) As Customer
Cust.Creditworthy = Not Cust.Creditworthy
In C#, the code looks like this:
public static Customer operator !(Customer cust)
cust.Creditworthy = !cust.Creditworthy
I can now toggle the creditworthiness of a Customer object in C# like this:
cust2 = !cust;
Postfix and prefix conventions are also honored with operators that support it. The primary difference in overriding binary operators (e.g. +, -) is that your operator method is passed two parameters: the object on either side of the operator.
Like I said: I'm not sure if this is a tip or bad advice, but I had a client ask me how to do it so people do seem to care.
Posted by Peter Vogel on 10/16/2012 at 1:16 PM1 comments
Entity Framework gets all the attention, but there's still something to like about ADO.NET DataSets. For instance, one reason that typed DataSets remain popular is that you can dramatically simplify your code by extending the DataSet with your own custom TableAdapter methods. All you have to be able to do is create an SQL statement in the Visual Studio query designer: Visual Studio will generate the code for you.
Ordinarily, to fill a table in a DataSet you need a half-dozen lines to open a connection, create an adapter (with its commands and parameters), set values in the adapter's parameters, call the adapter's Fill method, and then retrieve the resulting table (without, of course, forgetting to close the connection).
Update, insert, and delete statements aren't any simpler. What's especially irritating is that the code is virtually identical from one retrieval/update to another: really, only the SQL statement changes. With a custom TableAdapter method, though, you just call a method, passing the values required by your SQL statement.
When you create a typed DataSet, you get a TableAdapter with two methods on it for each table you drag into the DataSet: You get a Fill method that loads data into a DataTable but doesn't return anything, and a GetData method that fills the DataTable and then returns the DataTable to the calling code. As an example, here's the GetData method in action, retrieving all the rows in Northwind database's Orders table into a DataTable in a DataSet and then returning the DataTable:
Dim nwTB As New Northwind.OrdersDataTable
Dim nwtba As New NorthwindTableAdapters.OrdersTableAdapter
nwTB = nwtba.GetData
To create your own GetData, Fill, or update method, first right-mouse click on your table in the TableAdapters area at the bottom of the table and pick Add Query. That will bring up the query wizard where you can choose between using an SQL statement to retrieve your data, select from existing stored procedures, or create your own stored procedure.
Assuming you select Use SQL Statements, you'll be taken to a page that allows you to select the kind of SQL statement you want (everything from Select to Insert statements). After that choice, you'll be shown a default SQL statement you can modify. If you're not confident about your SQL writing skills, click the Query Builder button at the bottom of the dialog to be taken to Visual Studio's form-based query builder.
Once you've finished writing your SQL statement, the wizard will take care of writing all the ADO.NET code for you—all you have to do is name the method that will be added to your TableAdapter. For SQL statements, the wizard even generates a Fill and a GetData method. So to call a SQL statement that fills a DataTable with orders for a particular customer and hands the DataTable back to you, you just need this code:
Dim nwTB As New Northwind.OrdersDataTable
Dim nwtba As New NorthwindTableAdapters.OrdersTableAdapter
nwTB = nwtba.GetDataByCustomerID("ALFKI")
If you're paid by the hour, feel free to write the ADO.NET code. But this is the best kind of code-generation solution, because it allows you to concentrate on the one part of the code that matters -- the SQL statement -- while the boilerplate code is taken care of for you.
Posted by Peter Vogel on 10/09/2012 at 1:16 PM0 comments
It's not unusual to include a link in your page with a URL that points to a PDF file to let your users view the file on their computer. However, you can also control, through the URL, where and how the PDF file is displayed: just add a hash/pound sign (#) and some parameters to the PDF's URL.
For instance, the page parameter lets you open the PDF file at a specific page. This example opens the file at page 3:
You can also set up a search term for the user and position the view on the first appearance of the term (with the term highlighted) using the search parameter. This example searches for the word "test":
You're not limited to just positioning the user in the document. You can also specify how the document is to be displayed by using the view parameter. You can also combine parameters using the ampersand (&). This example repeats the search from the previous example but also fits the whole page into the view:
Additional parameters let you turn on (or off) toolbars, panes, and draw highlight boxes around arbitrary text. Adobe has a document (in PDF, of course) describing all of the options.
Thanks to Larry Raby for letting me in on this!
Posted by Peter Vogel on 10/03/2012 at 1:16 PM0 comments
A reader responded to an earlier tip on Visual Studio keyboard shortcuts by recommending VsVim, by Jared Parker. If the idea of never taking your fingers off the home row of your keyboard again, never having to use a menu, and never, ever reaching for the mouse sounds like heaven to you, then Jared's right: you should be looking at VsVim.
If using the letter d to delete, using uppercase D to delete to end of line, and using dd to delete a whole line is something you'll remember, then you're probably a veteran Unix programmer. In that case, you'll find the Visual Studio focus on WIMP (Windows, Icons, Menus, Pointer), well, wimpy. VsVim will put you back in control.
If you're as old as me, you remember vi as the world's most powerful keyboard editor -- the populariser (if not the inventor) of the Ctrl-Alt-Shift-meta-Coke-Bottle keyboard shortcut combination. You could do anything with vi if you knew the right keyboard combination. I've never been a keyboard-oriented person, but even I grew to have a nagging affection for the power of vi's keystroke combinations -- and my co-workers who were keyboard oriented loved what they could do with vi without taking their hands off the home row keyboard.
Vi gave birth to vim (vi iMproved), which added mouse support and even more editing commands. Now there's VsVim, which delivers vim functionality as a Visual Studio add-in. You can get VsVim from the Visual Studio Gallery site, or through Extension Manager from within Visual Studio.
It's an excellent package: reliable, quick, and it doesn't seem to fight with other add-ins (I used it with ReSharper installed, for instance). It's not overbearing in re-assigning your keys, so while you'll pick up lots of new keyboard commands, you shouldn't lose any of the ones you're used to. From the time I spent playing with it, it looks like a great tool for the keyboard oriented (and a free one).
However, VsVim is also a single-developer project and you might be more comfortable with a product that has a whole company behind it. If so, you should check out ViEmu
. ViEmu adds more vi-related features and also works in Outlook and SQL Server (but costs actual money).
Posted by Peter Vogel on 09/25/2012 at 1:16 PM0 comments