I've just run into an odd problem when attempting to overwrite exiting files using VB.NET and the File.Copy function. When I do this I get a System.UnauthorizedAccessException.

A bit of research revealed that the files being overwritten had their read-only attribute set, so I was able to use the following code to remove the read-only attribute before overwriting the file.

'---Make sure file exists and has READONLY attribute set. If it does, flip READONLY attribute.
If File.Exists(sInstallDescriptionFile) = True AndAlso (File.GetAttributes(sInstallDescriptionFile) And FileAttributes.ReadOnly) Then
File.SetAttributes(sInstallDescriptionFile, File.GetAttributes(sInstallDescriptionFile) Xor FileAttributes.ReadOnly)
End If

File.Copy(sSourceFullName, sDestinationFullName, True)

Eureka! After much searching, I've found that it's possible to install a service from VB.NET using only a couple of lines of code. Here's the URL:
http://weblogs.asp.net/sebastianweber/archive/2004/03/10/87170.aspx

In summary...

You need to add a reference to System.Configuration.Install

To install:
Dim sInstallParams() As String = {"MyService.EXE"}
System.Configuration.Install.ManagedInstallerClass.InstallHelper(sInstallParams)

And to uninstall:
Dim sInstallParams() As String = {"/u", "MyService.EXE"}
System.Configuration.Install.ManagedInstallerClass.InstallHelper(sInstallParams)

System.ServiceProcess.ServiceController
One of the nice things about Dot.Net is how Microsoft provided access to system functions that used to require nasty API calls and tons of research.

An example of this is the System.ServiceProcess.ServiceController class. I have a need to list all services installed on the local machine and I had just begun to try to figure out how to use the EnumServicesStatus API call when I happened upon System.ServiceProcess.ServiceController. It turns out that I no longer need to use EnumServicesStatus - I can now just reference the System.ServiceProcess.ServiceController.GetServices function, which returns an array of ServiceController objects. Each ServiceController object is well endowed with properties that describe the service. So much easier!

The System.ServiceProcess class also includes an System.ServiceProcess.ServiceProcessInstaller class. MSDN says this is what InstallUTIL uses so I'm thinking that I could write a sort of "super-InstallUTIL" that not only registers my service but also installs and configures it...


3-Tier Architecture
I had a really interesting conversation with a guy who is a Dot Net architect today. I spend a lot of time thinking about this stuff and it's great to have an opportunity to talk about various issues with someone who understands them so well.

One of the things we talked about was 3-tier architecture. I feel that for many people 3-tier is a sort of golden standard - sort of like "make everything a class" and "don't use GOTO statements" - that works in most cases but not in all. I sent him an email to try to explain what I thought and have decided to post it here as well.

My thoughts on 3-tier development in a corporate setting:

In a corporate development environment, ROI rules. There are always
more pending projects than resources to work on them and managers
often do not have abackgrounds. The culture is often one of immediate
gratification, of the "big win" where the ultimate quality of the
solution is less important than making the requesting manager feel
that his or her immediate need has been addressed.

It is my feeling that in this environment 3-tier architectures
are sometimes not the best solution: A three-tier solution often
trades complexity for scalability - however for many corporate
projects scalability is unlikely to be an issue. In contrast
additional complexity can increase the amount of time necessary to
implement a small change or additional feature. Additional complexity
also means more time is necessary to test and debug - time that is not
always available in a corporate environment. Finally, software
quality is a hard sell for non-IT managers who are simply attempting
to build something "good enough" to solve an immediate problem.

Rather than a formal "3-tier" architecture where UI, database and
business logic are rigidly segregated I have used rings of
encapsulation. If there is a task which is common to several
applications then in my feeling it makes sense to turn that task into
a common component - an assembly, a module in a shared code library
and/or perhaps even a seperate application (for example, security).
DotNet makes this wonderfully easy with its support for
object-oriented development and for debugging of assemblies integrated
into ASP.NET web pages (vs COM).

As a corporate developer, this has worked well for me. I have often
been asked to create applications based on a perceived need that later
was revealed not to exist. Because I was allowed to define the
architecture, I could rapidly create something that was little more
than a prototype, often reusing large sections of other applications.
If the application was proven to have benefit, I could extend and
enhance. If need for the application never materialized (manager's
misunderstanding of his/her workflow) than I did not waste a lot of
effort.

In the environments in which I have worked for the past 10 years, I
feel that 3-tier would not have delivered significant benefit and
would have taken longer to implement and maintain. This is not to say
that 3-tier does not have its place, especially with large
applications, applications with many developers involved, or
applications where performance is critical (such as high-volume web
sites).