Service Problem, InstallUtil fails. I'm stuck ...

[Guest]

Hi there

The following is a description to reproduce the problem. I do not know if this is a bug in the .NET environment/framework (I suspect it is), or if there is something that I am doing wrong. But I am definitely stuck on this one. I cannot find a solution

Make a new C# service project, and add an installer for the service (using menu). Set properties for a test scenario, don't modify code. Run InstallUtil, everything installs fine. Uninstall afterwards
Then, add a reference to an assembly, and add to the service project a class that derives from a class in the other assembly. In my case, the referred assembly contains a base threading class, then in the service project I derive from the base class to make the service main thread. Rebuild, then run InstallUtil. This fails with the following error message

<error_message
An exception occurred during the Install phase
System.InvalidOperationException: Unable to get installer types in the c:\...\visual studio projects\service bug test\service bug test\obj\debug\service bug test.exe assembly
The inner exception System.Reflection.ReflectionTypeLoadException was thrown with the following error message: One or more of the types in the assembly unable to load
</error_message

I don't know if this has something to do with the assembly I am referring to. Should this assembly be special in some way for the install utility to work? Is this a known issue perhaps? All help is appreciated

Dev Env : C
..NET Framework: v1.1.432
MDE 2003 : v7.1.308
InstallUtil : 1.1.4322.573, from .NET framework v1.1.432

Thank you very much
Tom Tempelaere.

 

[Guest]

Hi there

After talking with other C# developers, I've come to the conclusion that this is a bug in some part of the .NET framework or the InstallUtil utility, I can't tell where. Someone from Microsoft ought to look at the problem, and fix it for the new release of C# (or the next SP, if there is one). That is, if it really _is_ a bug and not lack of my knowledge, but I suspect it is a bug

The workaround is to make a new assembly that contains the concrete threading class, and refer to that assembly from the service project. This works without problems

I downloaded several C# service projects from the net, and I noticed that these all avoid the problem. For instance, injecting the base classes in the service project (bad bad bad), or, make a new assembly with the service implementation classes (the workaround I described)

PS: Is there a newsgroup/site where one can address bugs in the framework

Thank you
Tom Tempelaere.

 

[Guest]

Hi people

The same problems with InstallUtil exist when the service assembly uses a static property defined in another assembly. The error message is the same. The (obvious) workaround is to not use static properties, and use static methods instead

Thanks
Tom Tempelaere

 

[Guest]

Hi

The workaround doesn't seem to work sometimes. I think either the InstallUtil utility is buggy, or the C# Service project is. I will try to send a bug report to MS

Tom

----- TT (Tom Tempelaere) wrote: ----

Hi people

The same problems with InstallUtil exist when the service assembly uses a static property defined in another assembly. The error message is the same. The (obvious) workaround is to not use static properties, and use static methods instead

Thanks
Tom Tempelaere

 

[Guest]

Hi again

Forget all I said in the other posts in this thread

The problem is not a bug, it is because I configured my InstallUtil as a tool in the Tool-menu (IDE), and gave as argument ($TargetPath). I thought that the target path was the path to the executable/dll of the startup project, well it isn't. There simply is no argument for the startup path ($StartupPath). I wonder why there isn't

So If you happen to be editing a class in a project that is not the startup project, the installutil with ($TargetPath) will install the wrong assembly. Hence the errors I got

IMHO, there should exist an argument like ($StartupPath) leading to the path of the Startup Project

My apologies for saying that this is a bug, it isn't

Thank you
Tom.