Embedded Technology Workshop

Some members of our team, including myself, have attended a small, half-day workshop on Microsoft Embedded Technologies. Here's how the agenda looked like:

TIME	TOPIC
12:30	Registration and light lunch
13:00 – 13:05	Welcome speech
13:10 – 13:30	Introduction: Why use Embedded? What are the benefits?
13:30 to 15:00	Module 1: Windows Embedded Standard – Development Suite, Tools and Utilities. Module 2: Embedded Enabling Features.
15:00	Tea/Coffee Break
14:30 to 16:00	Module 3: Demo: - Building an image using File Based Write Filter Module 4: Componentization of 3rd Party Drivers. Module 5: Demo: - Creating Custom Components in your image.
16:00 - 16:30	Q & A
16:30	Closing and thank you

It was held at the local Microsoft office (not Microsoft Office, but the actual place where like, people work). The office was pretty boring by the way - no huge Bill Gates portaits, no sacrifices etc ... maybe they clean up when they know strangers will be present.

Anyway, the topic was mostly about how to assemble your own embedded OS from parts of dismembered Windows XP or Windows Embedded Standard etc. Basically, if I know exactly what peripherial devices will my hardware use, I can only include drivers for these devices, hugely reducing the size of the OS. Also, I may choose to cut out other elements of the OS - I may get rid of the whole explorer shell altogether. They mentioned that the smallest OS they have actually seen used by one of the clients was about 8MB in size. Quite impressive compared to the standard XP footprint of about 1.9GB.

As they said, the goal of the workshop was to show the participants that the process of assembling your own OS is not as complicated as people usually think. Can't say they succeeded - looked fairly complex to me so far ...

P.S. I have no idea why blogger inserts so many empty lines before the table ... will try to fix it later.

by Evgeny. Also posted on my website

VSS => TFS converter application update

After a bit of thought, I decided what would be the easiest and the most convinient way to run my small application that helps to convert projects from VSS to TFS.

I will start the command line tool passing them together with parameters to cmd.exe application, and run cmd.exe with the -k parameter to prevent the command window from closing after the tool exits. I will keep the ID of the process that runs cmd.exe. Next time I run the cmd.exe, I will check if there is ID present, and if yes, I will kill the process, and then start a new one. This way the user's computer will not be littered with command windows.

So, the small class that would take care of process management looks like this

public class ProcessFactory
{
 private static int _currentProcessID = -1;

 private static Process _cmdProcess;

 private static ProcessStartInfo _startInfo;

 public static ProcessStartInfo StartInfo
 {
  get
  {
   if (_startInfo == null)
   {
    _startInfo = new ProcessStartInfo();
   }
   return _startInfo;
  }
 }

 public static void RunProcess(string filename, string args, string workingdir)
 {
  try
  {
   if (_currentProcessID > 0)
   {
    Process processToClose = Process.GetProcessById(_currentProcessID);
    if (processToClose != null)
    {
     processToClose.Kill();
    }
    _currentProcessID = -1;
   }

   StartInfo.FileName = filename;
   StartInfo.Arguments = args;
   StartInfo.WorkingDirectory = workingdir;

   _cmdProcess = Process.Start(StartInfo);

   if (_cmdProcess != null)
   {
    _currentProcessID = _cmdProcess.Id;
   }
  }
  catch (Exception ex)
  {
   Logger.LogInfo(ex);
  }
 }
}

And then I just call the RunProcess as many times as I want, but the user will not be bothered with "leftover" command windows

string args = "/k ssarc.exe -d- -i -y" + SettingsManager.GetSetting(Constants.VSSLOGIN)
 + "," +
 SettingsManager.GetSetting(Constants.VSSPASSWORD) + " -s" +
 SettingsManager.GetSetting(Constants.VSSDBFOLDER) + " " +
 SettingsManager.GetSetting(Constants.VSSARCHIVEFILENAME)
 + ".ssa" + " \"" + SettingsManager.GetSetting(Constants.VSSPROJECTNAME) + "\"";

ProcessFactory.RunProcess("cmd.exe", args, SettingsManager.GetSetting
(Constants.VSSINSTFOLDER));

.....

args = "/k ssrestor.exe \"-p" + SettingsManager.GetSetting(Constants.VSSPROJECTNAME)
 + "\"" + " -s" + SettingsManager.GetSetting(Constants.VSSARCHIVEFOLDER) +
 " -y" + SettingsManager.GetSetting(Constants.VSSLOGIN) + "," +
 SettingsManager.GetSetting(Constants.VSSPASSWORD) + " " +
 SettingsManager.GetSetting(Constants.VSSARCHIVEFILENAME) + ".ssa" +
 " \"" + SettingsManager.GetSetting(Constants.VSSPROJECTNAME) + "\"";

ProcessFactory.RunProcess("cmd.exe", args, SettingsManager.GetSetting
(Constants.VSSINSTFOLDER));

etc., until finished.

by Evgeny. Also posted on my website

Using the Process class.

I was not too loaded with work recently so I decided to write a small application that would help to automate the process of converting existing Visual SourceSafe projects to Team Foundation Server. The idea is to get some information from the user first, and then spare him from some manual tasks - running tools like ssarc, ssrestor or VSSConverter, manually creating and editing XML files etc.

When the application starts, the user needs to provide (or just check) the following information:

• A folder where Visual SourceSafe is installed
• A folder where Visual SourceSafe database is located
• Visual SourceSafe database administrator login credentials
• The name of the Visual SourceSafe project to be converted
• A folder that will be used during conversion to restore VSS database, keep XML files etc.
• SQL Server that will be used by the converter
• A name of the TFS and the port number
• A name of the project on the TFS where the converted files will go

A significant chunk of the application functionality is just wrapping the calls to command line tools so that the user does not have to bother with manually locating them, typing the correct parameters etc.

For that purpose, the .NET class Process is quite handy.
Here is the example:
To archive the VSS project MyProject which is in the VSS database located on MyServer into the archive file called MyArchive.ssa I need to run the following from the command line:

>"C:\Program Files\Microsoft Visual SourceSafe\ssarc.exe" "-d- -i -yadmin,password -s\\MyServer\ MyArchive.ssa \$/MyProject\"

To run this command from the C# code I can use the following code:

ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "ssarc.exe";
startInfo.Arguments = @"-d- -i -yadmin,password -s\\MyServer\ MyArchive.ssa \$/MyProject\";
startInfo.WorkingDirectory = @"C:\Program Files\Microsoft Visual SourceSafe";
Process process = Process.Start(startInfo);

This is quite self-explanatory.

There are a couple of things that I had trouble with however. First thing is logging. It would be nice to log the errors and messages that the process generates. This is possible, according to the MSDN article.

ProcessStartInfo Class

Standard input is usually the keyboard, and standard output and standard error are usually the monitor screen. However, you can use the RedirectStandardInput, RedirectStandardOutput, and RedirectStandardError properties to cause the process to get input from or return output to a file or other device. If you use the StandardInput, StandardOutput, or StandardError properties on the Process component, you must first set the corresponding value on the ProcessStartInfo property. Otherwise, the system throws an exception when you read or write to the stream.

However, if I redirect standard output to the text file, for example, the user is unable to see it. And some of the tools used required interaction with the user. So it looks like I either interact with the user, or log the messages somewhere.

Also, when the process completes, it closes the window where it was running. So, if there is a message shown by the process when it exits, the user does not have time to read it. It might be frustrating when the process exits with an error message and the user does not know what exactly the error was. And it can not be logged because the output can not be redirected somewhere - the user needs to see it on the screen.

I will still be looking for the 'elegant' solution for this, but so far I found a workaround: rather than starting the process itself, I can start the command line using the "cmd.exe" and pass the whole tool together with the parameters as a parameter to cmd.exe.

CMD

The trick is that specifying the /k parameter prevents the command window from closing after the process exits. Here is how the previous code will look like when changed according to my workaround:

ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "cmd.exe";
startInfo.Arguments = @"/k "C:\Program Files\Microsoft Visual SourceSafe\ssarc.exe" "-d- -i -yadmin,password -s\\MyServer\ MyArchive.ssa \$/MyProject\"";
Process process = Process.Start(startInfo);

I will be looking for a better solution when I have time to improve this application.

by Evgeny. Also posted on my website

Small Things Refreshed Today

I had to write a small Windows Forms application today. It just gets some user input, creates an XML file, sends it to the webservice, gets the response, parces it and shows the results to the user. Good thing is that I had to remind myself how to use two simple things.

1. Saving and retrieving values using the app.config file.

If I want to get some values from the app.config file, I can keep them in the appSetting section and the whole app.config file for the small application can be as simple as that

To read the values I need to do just the following (after I add a reference to System.configuration to the project):

string myFirstValue = ConfigurationManager.AppSettings.Get("MYKEY1");

To update the values I need to put a little bit more effort

Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
AppSettingsSection appSettings = config.AppSettings;

appSettings.Settings["MYKEY1"].Value = myNewValue1;
appSettings.Settings["MYKEY2"].Value = myNewValue2;

config.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("appSettings");

It is useful to know that this would not work at debug time, though - it will not throw an exception, but the values would not be updated too. I spent a few minutes trying to find out why it does not work before I understood that this behaviour is expected.

2. Creating the XML document.

Of course, for the purposes of my application, where the whole XML is maybe 10 to 15 elements, I could go with the following:

string myXML = "
";
myXML += "" + someID + "";
...
myXML += "";
return myXML;

The code would actually be shorter than the "proper" XML handling, take less time to write and maybe even will work faster (especially if I use a StringBuilder to concatenate strings). I did it the "proper" way, however - for practice.

To create a document

XmlDocument xmlDoc = new XmlDocument();

To create a declaration

XmlDeclaration xDec = xmlDoc.CreateXmlDeclaration("1.0", "UTF-8", null);

To create an element in a format of

myValue1

I created a small helper function

private XmlElement CreateElementFromNameValue(string name, string value)
{
 XmlElement element = xmlDoc.CreateElement(name);
 element.InnerText = value;
 return element;
}

To create an attribute to the element

XmlElement xmlHeader = xmlDoc.CreateElement("header");
XmlAttribute schema = xmlDoc.CreateAttribute("SchemaVersion");
schema.Value = "2.0";
xmlHeader.SetAttributeNode(schema);

To bring it all together

XmlDocument xmlDoc = new XmlDocument();
XmlDeclaration xDec = xmlDoc.CreateXmlDeclaration("1.0", "UTF-8", null);

XmlElement request = xmlDoc.CreateElement("request");
XmlAttribute schema = xmlDoc.CreateAttribute("SchemaVersion");
schema.Value = "2.0";
request.SetAttributeNode(schema);

request.AppendChild(CreateElementFromNameValue("MYKEY1", "myValue1"));
request.AppendChild(CreateElementFromNameValue("MYKEY2", "myValue2"));

xmlDoc.AppendChild(xDec);
xmlDoc.AppendChild(request);

Expected InnerXml of the xmlDoc

 myValue1
 myValue2

by Evgeny. Also posted on my website