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
z:
cd \All_Customer_Releases
md %releasedir%
cd %releasedir%
md Build1
cd Build1
c:
cd "C:\Documents and Settings\alex\My Documents\Visual Studio 2008\Projects\SolutionRoot"
cd "Setup1\Debug"
copy *.* z:
z:
cd ..
md Build2
cd Build2
c:
cd ..\..
cd "Setup2\Debug"
copy *.* z:
z:
cd ..
md Build3
cd Build3
c:
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

WSDL to ASMX

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 http://blogs.msdn.com/jasonz/archive/2009/02/20/a-new-look-for-visual-studio-2010.aspx 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 http://www.visualstudiogallery.com and http://www.codeplex.com/site/search?projectSearchText=%22Visual%20Studio%22%20%22extensions%22 for some examples.

Monday, January 26, 2009

Haskell and Reactive Programming

See http://www.haskell.org/frp 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 http://www.haskell.org/yale/publications.html 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#

http://tomasp.net/blog/functional-overview.aspx

"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#."

http://tomasp.net/blog/fsharp-dynamic-lookup.aspx

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 http://alex-tfs.blogspot.com/2009/01/best-practice-on-c-code-commenting.html 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 http://www.winnershtriangle.com/w/Articles.DocumentingCSharpSourceCode.asp which is an excellent intro to C# Code Commenting.

(2) Read http://www2.sys-con.com/ITSG/virtualcd/Dotnet/archives/0108/horan/index.htm 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: http://msdn.microsoft.com/en-us/magazine/cc302121.aspx)

(4) Download http://www.microsoft.com/downloads/details.aspx?FamilyId=E82EA71D-DA89-42EE-A715-696E3A4873B2&displaylang=en and install the product. If you skip this step then you will be very sorry.

(5) Go to http://www.codeplex.com/SHFB/Release/ProjectReleases.aspx, 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 http://msdn.microsoft.com/en-us/library/5ast78ax(VS.71).aspx 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 http://www.csharpfriends.com/statics/tools.aspx 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 http://www.codeplex.com/Sandcastle/SourceControl/ListDownloadableCommits.aspx and a google search such as http://tinyurl.com/sand-code-doc 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 http://alex-tfs.blogspot.com/2009/01/read-httpalex-tfs.html for ideas on enhancing this best practice.