Monday, November 16, 2009

Using DOS Batch commands to create release folder with DateTime

In my current endeavor I have a solution that contains 3 setup projects that each has a distinct purpose within the overall scheme of things. When I build the solution I'd like to be able to have all 3 setup projects' output all grouped together in one folder whose name reflects the unique datetime (to the second). That way I can uniquely identify at a later date the releases that get built. Here's how I do it with a DOS batch file.

for /F "tokens=1-4 delims=/- " %%A in ('date/T') do set DATE1=%%D%%B%%C
for /F "tokens=1-4 delims=:., " %%a in ('time/T') do set TIME1=%%c%%a%%b
set "dt1=%DATE1:~0,8%%TIME1:~0,1%%TIME1:~2,4%"
set releasedir=MySoftware_%dt1%_Release
cd \All_Customer_Releases
md %releasedir%
cd %releasedir%
md Build1
cd Build1
cd "C:\Documents and Settings\alex\My Documents\Visual Studio 2008\Projects\SolutionRoot"
cd "Setup1\Debug"
copy *.* z:
cd ..
md Build2
cd Build2
cd ..\..
cd "Setup2\Debug"
copy *.* z:
cd ..
md Build3
cd Build3
cd ..\..
cd "Setup3\Debug"
copy *.* z:

Please note that I changed the solution name and the names of the 3 projects to protect my customer's privacy.

I also include this batch file in the root folder of the solution where the .sln file is located. That way its tracked like all the rest of my source files in TFS Version Control.

Wednesday, November 11, 2009


Today I got 2 WSDL files from 2 different vendors who will be calling our web services to do delegated authentication for single sign on. Here's a todo list on what needs to be done to go from WSDL file to having web services that can be used by the 3rd party application as desired.

1. Use wsdl.exe to generate the .cs files.

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\wsdl.exe" "C:\MyWSDLs\third_party.wsdl" /out:"C:\MyCSs" /serverInterface

2. Create an ASP.Net website with 2 new ASMX files for these vendors with codebehinds.

3. Copy the generated .cs files' code (i.e. the ones in the C:\MyCSs directory) into the ASMX codebehind files.

Wednesday, February 25, 2009

Highlights Planned for VS2010

See for some snapshots of the new VS2010 user interface. Some things I like:

New support in the editor for outlining: Colors on margin indicating edit status, triangle glyphs, ellipses.

Improved New Project dialog: online template viewing, a search box, easier navigation, multi-targeting includes .NET Framework 4.0 as an option.

New Extension Manager: many third parties have built extensions to Visual Studio and now VS2010 will provide a robust management tool to better find/integrate/manage extensions. See and for some examples.

Monday, January 26, 2009

Haskell and Reactive Programming

See for introductory links.

"Functional Reactive Programming is a paradigm for reactive programming in a functional setting. A number of different systems have been proposed and and sometimes implemented: some with very specific application domains in mind, some aiming at hard performance guarantees, and some being general-purpose FRP implementations."

See for some publications.

Then see some articles from TomAsp.Net about applying Haskell and Reactive Programming to F# and C#.

(I.) - First class events in F#
(II.) - Introducing Reactive LINQ
(III.) - Useful Reactive LINQ Operators
(IV.) - Developing reactive game in Reactive LINQ

TomAsp.Net on F#

"Thanks to the combination of C# 3.0 and F#, this article shows the ideas in a way that should be familiar to you in C#, but also shows a further step that you can take with a primarily functional language F#."

A feature that is usually present in dynamic languages can be very nicely used in statically-typed F# as well. Using F# quotations we can work with a representation of record field, which is in many ways similar to symbols known from Ruby (and similar features in other dynamic languages). Even though it is possible to achieve similar things by using strings using .NET reflection, the sample solution demonstrated here has one important advantage - the code is statically type-safe, which makes the code more robust.

Friday, January 2, 2009

Future Improvements on C# Code Commenting

Read to see a tutorial I wrote on what I consider to be the current "best practice" for C# Code Commenting. I have a few suggestions on future improvements to this "Best Practice":

(1) There should be a way to automate adding a post-build event for source code projects to have the Sandcastle CHM generated as part of the build.
(2) Certainly other project documentation (such as project charters, requirements documents, design/architecture documents, TFS reports (i.e. builds, work items, changesets, etc.) and other artifacts can be integrated into the post-build event.
(3) Certainly the whole post-build process done locally on auto-building the CHM file and including other artifacts can be included as part of the TFS Build process.
(4) Certainly templates with the HP logo, SLM-labels, and other process needs can be integrated into the help-files generation process.
(5) Considering that code comments are compiled into a XML file using a defined schema we can always customize the documentation however we want with XSLT, third party tools, etc.
(6) As Sandcastle is "open source" and Visual Studio is quite extensible it should be possible to specify custom XML tags that can be processed to generate whatever output or perform whatever tasks we want done at build-time.

Do you have any suggestions to add?

Best Practice on C# Code Commenting

For the next 30 minutes I recommend you do the following 7 steps. They'll teach you how to become proficient on a best practice for self-documenting your C# code in projects done using Microsoft Visual Studio. The same lessons apply for other .NET languages but I mention C# because its the most popular one. Once you've learned this process I'm confident you will use it for now on because it automates the documentation process for all development work to allow you to build HTML/Help files on-the-fly. Make sure you have Visual Studio 2005 or later installed on your workstation and that you've been able to successfully create and build a solution/project before proceeding with these steps.

(1) Read which is an excellent intro to C# Code Commenting.

(2) Read for a nice explanation on code commenting.

(3) Run Visual Studio, open a solution/project and follow the following instructions. (a) Open the property page for the project, usually by right-clicking on the project in the Solution Explorer, and click Properties. (b) After the dialog has opened, click the Configuration Properties folder. (c) Click the Build option. (d) In the right pane, there will be a property field called XML Documentation File. Set this to the path and file name of the desired file. The path entered is relative to the project directory, not absolute. (e) Put some "Hello World" text in a summary tag on at least one class/member within the project. (f) Build the project and view the XML Documentation File to see your "Hello World" text. (source:

(4) Download and install the product. If you skip this step then you will be very sorry.

(5) Go to, download the latest "Sandcastle Help File Builder Installer" MSI file and install. Then run it on your desktop start menu as follows: "All Programs -> Sandcastle Help File Builder". In the GUI click the ADD button to include the DLL file that corresponds with the assembly you generated in Step (3)(f) of this tutorial. Then select "Documentation -> Build Project" from the menu to build a Help file. Finally select "Documentation -> View Help File" from the menu to see the help file and search for your "Hello World" text.

(6) Read on recommended documentation tags and try them out in the project you used in Step 3. Build the project in Visual Studio. Then build the help file in Sandcastle to see the resulting help file.

(7) Read to see some other code commenting tools for .NET. However I recommend using Sandcastle because it has plenty of functionality, its source code is freely available at and a google search such as shows that there is sufficient documentation, assistance and community support for Sandcastle's future.

Did you do all 7 steps and bookmark this link for future reference? If so then you should now be sufficiently proficient enough on the current best practice for self-documenting your C# or VB.Net code in projects done using Microsoft Visual Studio. Congratulations Guru!! See for ideas on enhancing this best practice.

Thursday, January 1, 2009

Using Routines in Programming

The longer I code the more I've learned that the key to good programming is in how you approach writing routines. Steve McConnell at lists the following 8 reasons and I provide commentary.

  • Reducing complexity - I like to keep my routines short enough so I can read the routine declaration line to the bottom "}" all within one Visual Studio window. That's usually about 40 lines.

  • Avoiding duplicate code - I agree its the most popular reason for routines.

  • Limiting effects of changes - Doing the repeatable job in one place is important and that's why good requirements analysis and good software design/architecture up-front is essential in creating good coding practices.

  • Hiding sequences - This is why good routine-writing is essential to good object-oriented programming as its through hiding sequences in routines that we accomplish good encapsulation.

  • Improving performance - without good, organized routines you will never figure out where the bad-performing code is located

  • Hiding data structures and global data - good for encapsulating, sometimes bad for documenting the data structures' usage so that future DBA's and architects can read the code and make future changes or integrated systems.

  • Promoting code reuse and planning for a family of programs - This is where object-oriented programming provides real value with routines. And with the [obsolete] tag in C# and other code management tags & comment sections for .NET routines it makes it much easier to plan, document and validate code reuse or lack-of-reuse.

  • Improving readability - well-naming and keeping the size of the routine down to 20-40 lines is vital. Making routines too short or not designing the high-level algorithm well will cause what I call "sub of sub of sub of sub of sub ... I'm lost and can't find the code" syndrome. Basically its not easy to have too many nested levels of subroutines to dig through in order to find the code you need to work with and this is a common problem I run across when the subroutines are too short and the algorithm was either not well thought-out or its undergone considerable change.

  • Improving portability and isolating use of nonstandard language functions - interfaces and gateways from C# into COM libraries, external web services, external "C" code, etc. are well-managed through good routine writing.

  • Isolating complex operations - this is one of the greatest use of routines - any complex task must be done through ONE routine with calls to multiple subroutines in cases where alot of code is needed

VS2010 Planned Features and "Later" Features

for a list of planned features for Microsoft Visual Studio 2010 and some features planned for future features AFTER Visual Studio goes out.

For VS10:

* A new Windows Presentation Foundation-based (WPF) text editor
* More “modern,” with more of a WPF look and feel throughout the suite
* Smaller in size (in code and data) than Visual Studio 2008
* More reliable and modular

For some time “later”:

* Visual Studio Tools for Applications (VSTA) used for macros, plus other “end-user extensibility” improvements
* The ability to create more add-ins in managed code
* Full WPF shell
* Extensive support for the parallel framework for multicore hardware

Like just about every Microsoft product these days, VS 10 is going to get the Software+Services treatment ....

New Microsoft Programming Language Code-Named "D"

According to

A handful of Microsoft’s top developers are working to create a new programming language, code-named “D,” which will be at the heart of the Microsoft’s push toward more intuitive software modeling.

D is a key component of Microsoft’s Oslo software-oriented architecture (SOA) technology and strategy. Microsoft outlined in vague terms its plans and goals for Oslo in late fall 2007, hinting that the company had a new modeling language in the works, but offering no details on what it was or when the final version would be delivered.

D will be a declarative language aimed at non-developers, and will be based on eXtensible Application Markup Language (XAML), sources, who asked not to be named, said.

Sources close to Microsoft confirmed the existence of D, which they described as a forthcoming “textual modeling language.” In addition to D, sources said, Microsoft also is readying a comlementary editing tool, code-namd “Intellipad,” that will allow developers to create content for the Oslo repository under development by Microsoft.

5 Key Areas of Microsoft Oslo

See for the following on the “Oslo” advancements that will be delivered through Microsoft server and tools products in five key areas:

Server. Microsoft BizTalk Server “6” will continue to provide a core foundation for distributed and highly scalable SOA and BPM solutions, and deliver the capability to develop, manage and deploy composite applications.

Services. BizTalk Services “1” will offer a commercially supported release of Web-based services enabling hosted composite applications that cross organizational boundaries. This release will include advanced messaging, identity and workflow capabilities.

Framework. The Microsoft .NET Framework “4” release will further enable model-driven development with Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF).

Tools. New technology planned for Visual Studio “10” will make significant strides in end-to-end application life-cycle management through new tools for model-driven design of distributed applications.

Repository. There will also be investments in aligning the metadata repositories across the Server and Tools product sets. Microsoft System Center “5,” Visual Studio “10” and BizTalk Server “6” will utilize a repository technology for managing, versioning and deploying models.

David Chappell on Microsoft Oslo

See for the following:

Some Oslo details first went public in June of this year at TechEd. As described then, the code name "Oslo" applied to three things: a new version of Windows Workflow Foundation (WF), a server for running WF applications and others, and a set of modeling technologies, including a repository and visual editor. All of these technologies can be used together, so putting then under an umbrella code name made some sense.

Microsot Oslo and Visual Studio 2010

Planning a technology roadmap for the next few years requires that we know what's coming up from Microsoft with Oslo, Visual Studio 2010, etc. I'm not exactly sure how Oslo and VS 2010 will affect each other as Microsoft is wisely keeping all the details under wraps. I just know that their core functionality must be married as Oslo is the coding foundation for future Microsoft software code development and Visual Studio is the future tool for making it all happen. Stay tuned or be sorry!!

Suggested links: