Visual Studio 2008 has a whole bunch of features in it that I never use, or have had the time to learn; but there are some features that all developers will find very useful. In Stephen Walther's post on the topic, he provides us with 10 of them ... 5 of which I knew about already - but the other features are good, too.
Essential Visual Studio Tips & Tricks that Every Developer Should Know
I agree it was time for a new logo for the .NET Framework; just not sure I'm exactly in love this one. It's better than the one they had before, so it'll work. However, I thought they did a good job with the new website redesign. All in all, it'll be nice for .NET to have a fresh new look for a while.
http://www.microsoft.com/net/
http://microsoftpartnerevents.com/acrossamerica/Atlanta.aspx
This service pack includes full support for SQL Server 2008 (including support for new date and file stream capabilities), new features for ASP.NET AJAX, performance improvement for WPF, and more!
http://www.microsoft.com/downloads/details.aspx?FamilyId=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en
Tracey and I have been on Facebook for about 2 weeks, so we're still getting the hang of things. While I was checking out some other features, I found that there's a development kit available to create applications using Facebook data using Visual Studio Express Editions - both web and windows applications. Could be useful!
http://www.microsoft.com/express/samples/facebook/
Even though I used previous versions of Visual Basic (and VBScript) for a short time before beginning .NET development, I consider myself a C# coder. Not only was C# the language I used to learn .NET, it is only the one that I like better. I learned it faster, it was easier for me to read, and it was just a more natural fit for me. A mentor of mine calls it "The Programming Language of the Gods". Don't know if I'd go that far, but it has served me well.
However, because the current project I'm working on, I have been forced to the dark side of VB.NET. So far it's been fine; but every once in a while I run into a snafu with the syntax. Like yesterday, I wanted to create an event to be shared among several controls in a WinForm. In VB.NET, you have to specify a Handles clause that assigns it to a particular control/event. My fellow consultant was able to let me know that I can specify multiple control/events in the Handles clause by separating them with a comma. That solved the problem solved!.
If you ever find yourself in this situation, check out this post by Kathleen Dollard called What a C# Coder Should Know Before They Write VB; and make sure you read it sooner than later to save yourself some aggravation.
UPDATE (7/25/2008) - Due to its great popularity and all of the feedback on this post, Kathleen has written a second edition of this post. It has 10 more things to look out for, and has several clarifications.
The term "separation of concerns" is something I've been thinking a lot about lately as it relates to programming. I was reminded of how important it is when I had to troubleshoot an method with over 300 lines of code that performed about 8-10 tasks. This would have been so much better if it were modularized into 8-10 methods, thus separating each concern (or task); this means I probably would have only had to deal maybe 15-20 lines of code. As it was, I ended up breaking up into about 4 methods, just so I could get my head around it.
As the Wikipedia definition in suggests in the link above, as well in this post, separation of concerns can also apply to your life. Instead of dealing with life's challenges all at once, it's always good to separate them by your roles or goals. Whether it's programming or life, doing this helps to ensure that a failure in one area doesn't lead to the entire thing failing. For example, if you're not very productive at work because you have personal problems, you have done a poor job at separating your concerns. If you're playing poor defense because you can't make a shot offensively, same thing. The inability to perform one task should not prevent the other pieces of an application from working. Right?
What I'm wondering is if you can ever have too much separation of concerns. Or maybe a better question is if there's ever a point where further separation won't hurt, but is also pointless. I have four children; if one of them has a problem with lying, it would not be fair to assume that all of them lie. That's a good separation, right. But what concerns do I draw from the one child being a liar? In fact, a parent would probably ask the child in anger, "Why did you lie to me?" And what's the answer we always get .... "I dunno." It makes us more angry; but sooner or later we realize that he/she is probably right. It doesn't matter why, we just need to find a way to make sure they think twice before he/she does it again.
I could have spent the time breaking that 300 lines of code into 8-10 methods (maybe even more.) But I think we need to ask ourselves the reason for doing so; and if the only reason is for the sake of separating concerns, I don't think that's a good enough. Sometimes, perhaps we should ask if there's a good reason to keep lines of code together; if you can think of one, it's time to re-factor it. I think separating with purpose is a much more responsible approach than blinding separating every chance we get. However, what is even more irresponsible is not to separate them at all.
One thing I've always loved about the .NET community is our willingness to share. I've recently come across yet another free avenue for getting a .NET overview - it's called .NET University. They are actually providing courseware that's starting to be taught in several major cities, and that you can also download & teach to others. The newest course made available is ASP.NET University, which will premier in Atlanta (Alpharetta, Georgia to be exact!)
Their schedule always shows a few courses available in Orlando, including an overview of BizTalk and Sharepoint. Hopefully this will catch fire and other courses & locations will be available soon.
It appears that even though we're in some sort of recession (depending on who you ask), companies still need software built - and for it to be built well. That means that developers with good experience are still in demand. In the case of the Atlanta area, recruiters have plenty of jobs for those with good .NET skills. It is a great time to be a Microsoft software developer.
It is no different with the great company that I work for ... Magenic Technologies. Magenic employs over 200 consultants nationwide, with 20 consultants based in our Atlanta office. Now that we have another salesperson on staff (who just two successful years as a Account Executive for Microsoft) and all of our consultants working with clients in the field, we are looking for more talented developers to join our fantastic group here in Atlanta. The more WPF, CSLA, or BizTalk experience you have the better; but we'll talk to anyone with deep .Net skills.
It's been wonderful for me to work for Magenic for severals reasons. I've always been easily bored over time working on the same ol' application; as a consultant, I get to jump from one client to the other, which keeps things exciting and challenging for me. Being surrounded by other experts (most that know more than I do) is also a plus. At Magenic, you are also encouraged to develop your skills and influence outside of Magenic - which means they support me teaching classes with Learning Tree. The thing I appreciate the most is being considered an asset and being valued as such - from the CEO all the way down to my GM in Atlanta.
If this sounds like an environment you would enjoy, contact me and I'll get you connected wiht the greatest recruiter in the world! Don't worry if you don't live in the Atlanta area; they'll help with relocation expenses for the right person. Just don't be afraid of travel, you will be asked to do so. Holla!
There are a few articles on the Internet that show how to automate the mail merge, including this one from Microsoft. However, most of the ones that I found also include code to create a data source and a form letter from scratch. If you already have the data, there's no reason re-populate it into a new data document - only to have to delete it when you done. And you certainly don't want to maintain form letter content from your code, either.
This article shows how to automate a Microsoft Word mail merge with an existing form letter (not generated from code), and the ability to connect to an existing data source without having to recreate it each time. Here are the steps:
The Form Letter
The document that is used to generate the letters (the form letter) should be setup the same way you always would in Microsoft Word 2003. However, when you setup the data source, go ahead and save it so that you ODC file it generates later. Go ahead and test the Mail Merge to make sure it works.
The Data Source File
The ODC file that you saved is under My Documents\My Data Sources. The advantage of having this file is that you can change the file when the database connection changes (i.e. when you move your application from development to production.)
The Application
This article uses a Microsoft Visual Studio 2005 solution in C# to build the windows application that performs the automatic mail merge. You'll need to add a reference to Microsoft Word 11.0 Object Library in order for this to work. Once you do that, here's the code you need to get it done.
Microsoft.Office.Interop.Word.ApplicationClass wordApp = new
Microsoft.Office.Interop.Word.ApplicationClass();
Microsoft.Office.Interop.Word.Document wordDoc = new Microsoft.Office.Interop.Word.Document();
string rootpath = Application.StartupPath;
object vkMissing = System.Reflection.Missing.Value;
object vkReadonly = false;
object vkVisible = true;
object vkFalse = false;
object vkTrue = true;
object vkDynamic = 2;
object vkFileToOpen = (object)rootpath + "\\form_letter.doc";
wordApp.Visible = true;
try
{
wordDoc = wordApp.Documents.Open(ref vkFileToOpen, ref vkMissing, ref vkReadonly,
ref vkMissing, ref vkMissing, ref vkMissing, ref vkMissing, ref vkMissing,
ref vkMissing, ref vkMissing, ref vkVisible, ref vkMissing, ref vkMissing, ref vkMissing,
ref vkMissing, ref vkMissing);
wordDoc.Select();
wordDoc.MailMerge.OpenDataSource(rootpath + "\\conn.odc", ref vkMissing,
ref vkTrue, ref vkFalse, ref vkMissing, ref vkMissing, ref vkMissing, ref vkMissing,
ref vkMissing, ref vkMissing, ref vkMissing, ref vkMissing, ref vkMissing, ref vkMissing,
ref vkMissing, ref vkMissing);
wordDoc.MailMerge.Destination =
Microsoft.Office.Interop.Word.WdMailMergeDestination.wdSendToNewDocument;
wordDoc.MailMerge.Execute(ref vkFalse);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
finally
{
wordDoc.Close(ref vkMissing, ref vkMissing, ref vkMissing);
}
Here's a sample project that uses this code. This post is from my other blog and wanted to make sure it was included in this one so that I don't lose it. I have not tested this with Microsoft Word 2007; when I do, I'll give you the update. Good luck with it.