# Friday, April 2, 2004

I have thought of doing this several times, but I always think about it when I'm not really ready to do it. That changed tonight.

Jeff Key reminded me to change my VS templates. It truly is very easy.

  • Go to %programfiles%\Microsoft Visual Studio .NET 2003\VC#\VC#Wizards\.
  • Select the wizard that you would like to change the template for (e.g. “CSharpAddClassWiz” for the general 'Add Class' case).
  • Enter the Templates\1033 directory of that wizard.
  • Edit the .cs file therein.

Very straight-forward. No longer will I feel need to delete those pesky “TODO:...” comments and such. And if I happen to be one of those 'open-curly-on-the-same-line' people, well - so be it! I can now get that as default behavior!

Thanks for the reminder, Jeff!

Friday, April 2, 2004 10:17:11 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]

From the Microsoft PressPass site:

Microsoft and Sun Microsystems Enter Broad Cooperation Agreement; Settle Outstanding Litigation

Ten Year Agreement Sets New Framework for Industry Cooperation; Reduces Cost and Complexity for Customers

What next? Israel and Palestine go to church together? Ireland and England sit down for a pint? Everyone refuses to kick anyone else off of the next Survivor island?

Friday, April 2, 2004 3:56:01 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]
# Wednesday, March 31, 2004

We've waited almost three decades for this. The original Star Wars Trilogy is finally coming to DVD! On September 21st, this classic series will be available for purchase. Or, what the heck, pre-order it now:

Wednesday, March 31, 2004 8:19:49 AM (Pacific Standard Time, UTC-08:00)  #    Comments [0]
# Tuesday, March 30, 2004

It took me long enough, but I've finally upgraded this blog to dasBlog version 1.5. What a pleasure to find no significant issues :-).

The only thing that I missed was backing up my theme. I'm not sure that I successfully recreated it or not, but it's good enough.

Tuesday, March 30, 2004 1:36:12 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]
# Monday, March 22, 2004

This will probably be the most useless thing I’ve posted to date on my blog, but I found it quite interesting.

Two weeks ago, I shipped a pair of DishNetwork tuner/pvr’s off to their mothership (had some problems with hard drives). As I tracked their progress on UPS, I noticed that they went in opposite directions: one went east along the Columbia River, the other south on Interstate 5. Of course, I couldn’t wait to see which of the packages arrived at their destination (El Paso, Texas) first and wondered why both wouldn’t go that ‘more efficient’ route.

Well, I finally remembered to check on them today. Despite one going through California and the other through Colorado, they both arrived in Albuquerque, New Mexico within an hour and a half of one another, three days later. From their, they finished their journey to El Paso together.

I don’t know why I care about this, but I find it interesting. I suppose it suggests that UPS is pretty darn efficient overall. Anyway, that’s the interesting Monday story.

Package Progress:

Date

Time

Location

Activity

Mar 12, 2004

12:04 P.M.

EL PASO, TX, US

DELIVERY

6:38 A.M.

EL PASO, TX, US

OUT FOR DELIVERY

6:00 A.M.

EL PASO, TX, US

ARRIVAL SCAN

Mar 11, 2004

11:04 P.M.

ALBUQUERQUE, NM, US

DEPARTURE SCAN

3:42 P.M.

ALBUQUERQUE, NM, US

ARRIVAL SCAN

Mar 10, 2004

12:56 A.M.

RICHMOND, CA, US

DEPARTURE SCAN

Mar 9, 2004

10:30 P.M.

RICHMOND, CA, US

ARRIVAL SCAN

8:30 A.M.

ROSEBURG, OR, US

DEPARTURE SCAN

7:06 A.M.

ROSEBURG, OR, US

ARRIVAL SCAN

3:28 A.M.

PORTLAND, OR, US

DEPARTURE SCAN

Mar 8, 2004

10:14 P.M.

PORTLAND, OR, US

ARRIVAL SCAN

9:46 P.M.

TUALATIN, OR, US

DEPARTURE SCAN

8:38 P.M.

TUALATIN, OR, US

ORIGIN SCAN

4:11 P.M.

TUALATIN, OR, US

PICKUP SCAN

Tracking results provided by UPS: Mar 22, 2004 9:06 P.M. Eastern Time (USA)
 

Package Progress:

Date

Time

Location

Activity

Mar 12, 2004

12:04 P.M.

EL PASO, TX, US

DELIVERY

6:38 A.M.

EL PASO, TX, US

OUT FOR DELIVERY

6:00 A.M.

EL PASO, TX, US

ARRIVAL SCAN

Mar 11, 2004

11:04 P.M.

ALBUQUERQUE, NM, US

DEPARTURE SCAN

2:29 P.M.

ALBUQUERQUE, NM, US

ARRIVAL SCAN

4:16 A.M.

COMMERCE CITY, CO, US

DEPARTURE SCAN

12:03 A.M.

COMMERCE CITY, CO, US

ARRIVAL SCAN

Mar 9, 2004

7:25 A.M.

HERMISTON, OR, US

DEPARTURE SCAN

7:15 A.M.

HERMISTON, OR, US

ARRIVAL SCAN

3:09 A.M.

PORTLAND, OR, US

DEPARTURE SCAN

Mar 8, 2004

11:40 P.M.

PORTLAND, OR, US

ARRIVAL SCAN

9:47 P.M.

TUALATIN, OR, US

DEPARTURE SCAN

8:32 P.M.

TUALATIN, OR, US

ORIGIN SCAN

4:11 P.M.

TUALATIN, OR, US

PICKUP SCAN

Tracking results provided by UPS: Mar 22, 2004 9:09 P.M. Eastern Time (USA)

Monday, March 22, 2004 6:49:34 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]
# Saturday, March 20, 2004

I have some vague recollection of this feature existing, but it wasn't until this last week that I needed it again:

When working on a project with multiple executables within the same Solution, Visual Studio can Start all of them when you debug if setup for it.

Simply right-click the Solution and choose Properties. Choose Startup Projects from the left pane, then select the Multiple Startup Projects radio button.

For each project listed, you may choose to start it normally or without debugging. By using the Move Up and Move Down buttons, you may change the order in which the projects start!

Saturday, March 20, 2004 1:51:33 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]

If only I would pay attention to the tool tips for a program, I would have been using this tip a long time ago:

To show or hide the formatting marks in Word (spaces, tabs, paragraphs, etc.), type ctrl+*. Quicker than using the mouse and a lot less likely to cause a repetitive stress injury.

Saturday, March 20, 2004 1:38:13 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]

This is kind of an old trick, but one I sometimes forget:

When editing in Visual Studio, simply hold down the Alt and Shift keys while typing Enter. This will put Visual Studio into full screen mode and provide a much larger working space.

Saturday, March 20, 2004 1:31:50 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]

In my networking class this term, we built a simple chat program. It’s nothing fancy – type in your name, a server, and see what others are posting.

I decided to learn a little bit about .NET Remoting in this exercise. I found numerous examples (including some chat programs) demonstrating how easy it was to create such a program and felt confident with choice I had made. The only thing I had to add to the consolidation of information I had found was a way to select the server one was using.

Yeah… just that.

Now, it’s entirely possible that I missed some nugget of information out there and even that there is a different (better?) way of doing this, but I think I learned something of value through this exercise.

First, the app.config file I was using that worked fine was as follows:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.runtime.remoting>
    <application>
      <client>
        <wellknown
          url=http://ServerName:7777/LeChat
          type="LeChat.Broker.LeChatBroker, LeChatBroker"
        />
      </client>
      <channels>
        <channel
          ref="http"
          name="client"
          port="8888"
        >
          <clientProviders>
            <formatter ref="soap" />
          </clientProviders>
          <serverProviders>
            <formatter ref="soap" typeFilterLevel="Full" />
          </serverProviders>
        </channel>
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

With this file, one only has to load the settings with:

RemotingConfiguration.Configure( "AppName.exe.config" );

Easy! Of course, if I want to change the name of my server, what do I do?

Some of the learning I had:

The app.config file is meant to be a quasi-read-only file. Although one can write to it through various means, it is loaded at the launch of the application and cached for use throughout the activation – once the program is running, changing the app.config would make no difference.

All of the examples I found for loading the configuration in code were nearly identical:

HttpChannel channel = new HttpChannel( 8888 );
ChannelServices.RegisterChannel( channel );
RemotingConfiguration.RegisterWellKnownServiceType(
      typeof( LeChat.Broker.LeChatBroker ),
      "http://" + serverName + ":7777/LeChat",
      WellKnownObjectMode.Singleton );

This did not provide all of the parameters needed to make the two-way communication possible between the client and the server. In fact, kept going back and forth between having the chat text show up only on the server, or only on the client – depending on whether I registered a … ServiceType, or a … ClientType. Aarrrggghhh!

Finally, I started looking at the overridden constructor on the HttpChannel. I saw something about a IDictionary of ‘properties’ and realized I might be on to something. I started reading about SinkProvider’s and felt even closer. Finally, I had constructed the complete block of code that allowed my little chat program to work and I could insert any server name I needed to:

IDictionary configurationProperties = new Hashtable();
IDictionary serverSinkProviderProperties = new Hashtable();
configurationProperties.Add( "ref", "http" );
configurationProperties.Add( "name", "client" );
configurationProperties.Add( "port", "0" );
serverSinkProviderProperties.Add( "ref", "soap" );
serverSinkProviderProperties.Add( "typeFilterLevel", "Full" );
SoapClientFormatterSinkProvider clientSinkProvider =
      new SoapClientFormatterSinkProvider();
SoapServerFormatterSinkProvider serverSinkProvider =
      new SoapServerFormatterSinkProvider(
        serverSinkProviderProperties, null );
HttpChannel channel = new HttpChannel(
      configurationProperties,
      clientSinkProvider,
      serverSinkProvider );
ChannelServices.RegisterChannel( channel );
RemotingConfiguration.RegisterWellKnownClientType(
      typeof( LeChat.Broker.LeChatBroker ),
      "http://" + serverName + ":7777/LeChat" );

This turned out to be a more substantial investment than I had expected. I did get a chance to learn more about how this stuff works and I’m looking forward to reading Ingo Rammer’s book " Advanced .NET Remoting" to learn more. However, I felt compelled to document what I did so that I can re-learn it all if needed.

Saturday, March 20, 2004 1:22:47 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]