(talking smart client – windows forms app here, not asp.net)

I was using System.IO.Directory.GetCurrentDirectory to find DLL’s that are to be loaded by reflection in a particular app. But when a user goes out and does something like look up something in windows explorer, that changes the definition of the system’s current directory and you are no longer pointed to the startup path. Then when the user tries to load up the next form – it can’t’ be found! Oops.

GetCurrentDirectory’s definition is “current working directory“. And even in the reference it explicitly says: “The current directory is distinct from the original directory, which is the one from which the process was started.“

So when you need to use the startup path, use the Application.StartupPath which is in the System.Windows.Forms namespace.

(oh, I’m just so embarrassed! 🙂 )

This seems to be the general response I got from everyone at the meeting. I’ll post on it myself soon. Michele is one of the best presenters I have seen. Combine that with her deep knowledge – and you have got an awesome presentation.

The initial website for VTSDA is now live.

If you are a Vermont Software Business or contractor, check it out and register for our first meeting. This is for any technology.

James Avery recently emailed me to see if I had experienced any problems with the refresh and some of the visualizers that I have written in the past.

As I had not yet bothered with the install I couldn’t confirm for him but we got a pointer from Scott Nonnenberg to check that the Microsoft.VisualStudio.Debugger.Visualizers dll was referenced in the project.

Yesterday I got the dvd so I went ahead and uninstalled the beta (but no the framework or other dependent stuff since apparently, the refresh only adds Team System). Then I discovered the same affect that James had. My custom visualizers did not work, but the ones that came with VS did.

Here is how I fixed it.

The quick list:
In your visualizer’s project
– Remove meehost.dll from references.
– Add a reference Microsoft.VisualStudio.Debugger.Visualizers
– Rebuild
– Copy resulting dll to My Documents\Visual Studio\Visualizers
In client application
-be sure that the visualizer’s assembly (dll) is NOT referenced

The Julie-style verbose explanation

The original project referenced meehost.dll. This needs to be removed and replaced with a reference to Microsoft.VisualStudio.Debugger.Visualizers. Note that if you leave meehost in there and add the other, you will learn that they have duplicate classes etc which is why I removed meehost.dll. (This is in the actual project where you build the visualizer). Rebuild the visualizer and copy the assembly into My Documents\Visual Studio\Visualizers folder.

This still did not fix the problem totally as I got a new error that happened on both my custom and the included visualizers. I noticed that my visualizer assembly was referenced in the client project. That shouldn’t be necessary as the visualizer is available to all projects once it’s copied into the (above mentioned) folder. So I removed that and voila – all was well.

Very excited to have Michele coming to Vermont to speak to Vermont.NET on Monday. Luckily she comes in Sunday night, and the leaves are already turning, so I plan to show off a bit of our beautiful little state to her before she heads right back to Boston as she has an 8:30 am talk at  SD East in Boston on Tuesday morning. Although we had planned a more leisurely Vermont trip for Michele, her hectic schedule has put her in the tough position of having to do a lot of travelling in a short amount of time that I do not envy and that I am so grateful she is doing. She is also speaking at the NH .NET Group on Thursday.

Michele lives in California, so this is a long trip for her. Her Vermont.NET and NHDNUG talks are both thanks to INETA.

At Vermont.NET, Michele will be doing a talk on leveraging HTTP Handlers and SOAP extensions to extend ASP.NET. I saw part of this when she did it for a WebCast in the early spring and have been very much looking forward to having her do it for Vermont.NET (and seeing the rest of it myself, as well). 

We are also fortunate to have a license of MindReef’s SoapScope to raffle off at the meeting, thanks to Scott Gagnon of MindReef.

I’m working on my deck for doing ink on the web for ASP.NET Connections. I wanted to be able to explain why the SDK 1.7 controls now enable this to work – which is all about the fact that the Tablet Team has modified the API to make the the InkPicture and InkEdit controls as well as the InkOverlay object work under partial trust. Having to explain it, once again, means having to understand it well enough to explain it, not just take that leap of faith.

So I FINALLY grok what is going on here! A big light just turned on. You know the difference between “uh huh” and “oooooooooooooooh!” (that’s a long “o” like DOUGH, not like “foo”) when you are trying to explain something to someone.

Although I grokked CAS on the machine – I hadn’t done any code download via using windows controls in web apps. And if you follow my blog you may know that I have been a big failure when it has come to my many attempts over the last few years to leverage no touch deployment and auto-updating (turns out my application architecture was way too complex for this).

If I had acquired this understanding earlier, I wouldn’t have hit so many walls when I was trying to deploy my doodling app a few weeks ago. I didn’t have the knowledge to give me the red flags that I was doing something incorrectly and I didn’t have the knowledge to understand why it didn’t work when I deployed it. Hmm, I may have gotten a few more points on my security test, too. I understood “does & doesn’t work” but I never really understood why! I can’t imagine how many people are out there in the same boat.

I might have to do a Julie version of this topic soon.

One of the three talks I am doing at ASP.NET Connections is What’s new in the BCL 2.0 for ASP.NET Developers (that’s an abbreviation of the title).

I am taking my “What’s New in the Whidbey Base Class Libraries” presentation that I have been doing since February and turning it on its’ ear a little bit. I thought of doing this because I had a conversation with an ASP.NET guru who was giving me grief for focusing on the BCL so much this winter. “Dude!,” said I, ” System.Web.NUTHIN’ don’t WORK without the BCL!”

So while many ASP.NET developers are spending their time focusing on the cool personalization and caching functionality in ASP.NET 2.0 or the ability to drag & drop your way to a website, I am going to try to call their attention to some key goo in the BCL that will help them write better code and write it more simply.

Champlain College has some .NET classes. I believe it’s in the continuing ed school. I couldn’t find the classes in the regular curriculum. They are one of the colleges in Burlington. I was happy to hear this. What it means to me is that .NET is finally really taking wing here.

I didn’t until today. http://www.vtsbdc.org/

“The SBDC mission is to strengthen existing business entities, and assist start-ups through high quality, no cost counseling, and high quality, affordable training programs”

What an awesome resource. It’s not uncommon for many of us developers who are contractors or small consulting firms to want some basic advice (maybe accounting or legal) but it doesn’t seem to justify the high cost of a lawyer or accountant.

I am on the steering committee for a new group being formed in Vermont, the Vermont Software Developers Association (working title maybe). The steering committee meetings are getting more frequent as we head to our goal of having our first official meeting at the end of September in downtown Burlington. There are statewide and regional software developer associations around the country. This is going to help Vermont businesses who are in teh business of software (consultants, contractors or vertical market software companies), regardless of the technology they use, share their business knowledge and hopefully help the rest of the world with this common problem of being shocked when they here there are software companies in Vermont. Vermont is so well known for its maple syrup, cheese, Ben & Jerry’s and of course our cows. There is a LOT of tech going on here. A lot of very good tech. Just looking at the Microsoft spectrum here, we have had a lot of developer’s and companies on board with .NET since the very beginning and now many are pretty advanced. Anyway, I’m very excited about this. I will be contacting people from different sda’s around the country to see if anyone would be willing to talk with us to give us ideas of what has and hasn’t worked for them. Unfortunately becuase part of most of the SDA’s goals is to promote their area’s business, there is a slight conflict of interest. But hopefully, I can find some folks who will see past that and just grok the good for the software developers as a whole.