Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Design Surface broken for Windows Services

2 views
Skip to first unread message

marc hoffman

unread,
Nov 5, 2004, 11:43:09 AM11/5/04
to
When trying to create a Windows Service application by creating a descendant
of System.ServiceProcess.ServiceBase such as:

type
TMyService = class(System.ServiceProcess.ServiceBase)

The design surface doesn't work (as it does in Visual Studio), stating the
following error: "An error occured while loading the document. Fix the
error, and then try loading the document again. The error message follows:
The designer can not be shown because deserialization threw an exception: No
top level designer for the type 'System.ServiceProcess.ServiceBase' could be
found.".

This happens with both Delphi 8 and the Delphi 2005 Borcon preview, for
Delphi and C# projects (while Visual Studio can design a ServiceBase just
fine). Am i missing something here, or is this just Yet Another Thing That's
Broken?

[Note also, that the above error message has a typo in "occurred", at least
according to my spellchecker. someone feeling bored enough to QC that?]

any comments would be appreciated,

--
marc hoffman
Chief Architect, .NET
RemObjects Software
http://www.chromesville.com

Mauro Venturini

unread,
Nov 8, 2004, 9:50:34 AM11/8/04
to
It is painfully evident that D8 is not up to the standards we Delphi users
are
used to (but from my previous experiences with VS, VS users should quite
used to).
Nevertheless, I think that the (WinForms) .NET designer, being part of .NET
SDK,
is only used by D8 but not part of it (as it is quite evident comparing it
to the
VCL.NET designer).
Therefore, I suppose that the error messages (and typos) are controlled by
MS,
not by Borland QA.
Moreover, the name of the designer for a certain SDK class is defined by an
attribute
of the class and I suppose it can not be changed without changing the
assembly
containing the class. The attributes for ServiceBase class are

[Designer('Microsoft.VisualStudio.Install.UserNTServiceDesigner,
Microsoft.VisualStudio, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a',
'System.ComponentModel.Design.IRootDesigner'),
InstallerType(typeof(ServiceProcessInstaller))]

So it seems that the required designer is
Microsoft.VisualStudio.Install.UserNTServiceDesigner that is not include in
the
.NET SDK. That is .NET SDK references something that is not included with
it.
Now, I suppose that even if Borland would want to write a replacement for
the
designer, "legal" reason (the name Microsoft.VisualStudio) would forbid it.
And I suppose that even if this problem did not exist Borland could not make
the designer work because the attribute used the "strong" name.
Summing up, I suppose that blaming Borland for this designer problem is a
bit
off the target.


"marc hoffman" <m...@spam.spam> wrote in message
news:418b...@newsgroups.borland.com...

marc hoffman

unread,
Nov 15, 2004, 10:11:32 PM11/15/04
to
Mauro,

> Summing up, I suppose that blaming Borland for this designer problem is a
> bit off the target.

that wasn't my intention; i merely wanted to clear up if i was doing
something wrong or whether this was a limitation of Delphi (which it seems
to be; regardless of who's to blame for it ;-).

Sergey M

unread,
Nov 16, 2004, 12:32:39 AM11/16/04
to
Yep, I've also noticed this long time ago. My Windows Service
submission shows the same exact symptoms. As a matter of fact, try
adding an installer to the project as

TMyServiceInstaller = class(System.Configuration.Install.Installer)

and you should it being broken the same way.

If Mauro is correct then #develop should be similarly broken. If
anyone has #develop installed it'd be interesting to see whether it
works or not.
--
Sergey Mishkovskiy
http://codecentral.borland.com/codecentral/ccweb.exe/author?authorid=106789
http://www.usysware.com/dpack/

Mauro Venturini

unread,
Nov 17, 2004, 3:35:10 AM11/17/04
to
Installer designer is broken for the same reason. These are its attributes
(using Reflector)
[Designer('Microsoft.VisualStudio.Configuration.InstallerDesigner,
Microsoft.VisualStudio, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a', typeof(IRootDesigner)),
DefaultEvent('AfterInstall')]
public Installer = class(Component)Name:
System.Configuration.Install.Installer Assembly:
System.Configuration.Install, Version=1.0.5000.0 It'd be also interesting to
see whether D8/9 can use these designers when they are present, that is when
VS is installed on the same machine. Maybe adding the VS folders to the D8/9
path search list...


"Sergey M" <n...@spam.com> wrote in message
news:419990b0$1...@newsgroups.borland.com...

Sergey M

unread,
Nov 17, 2004, 10:11:46 AM11/17/04
to
Mauro,

> Installer designer is broken for the same reason. These are its
> attributes
> (using Reflector)
> [Designer('Microsoft.VisualStudio.Configuration.InstallerDesigner,
> Microsoft.VisualStudio, Version=1.0.5000.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a', typeof(IRootDesigner)),
> DefaultEvent('AfterInstall')]
> public Installer = class(Component)Name:
> System.Configuration.Install.Installer Assembly:
> System.Configuration.Install, Version=1.0.5000.0 It'd be also
> interesting to
> see whether D8/9 can use these designers when they are present, that
> is when
> VS is installed on the same machine. Maybe adding the VS folders to
> the D8/9
> path search list...

Right. That's the same cause. The issue is that
Microsoft.VisualStudio.dll assembly is already distributed along with
the .NET SDK. This assembly has some other dependencies but all required
assemblies for the above mentioned designer are either there in the
framework installation folder or in the same SDK folder. Additionally,
all of those assemblies are installed in to the GAC.

So, I don't understand why Borland had chosen not to support some of the
commonly used designers for. They could've attempted to load the
assembly listed in the Designer attribute and deal with any error if
they occur during the assembly load.

BTW, this problem persists in both D8 and D2005.
--
Sergey M
http://codecentral.borland.com/codecentral/ccweb.exe/author?authorid=106789
http://www.usysware.com/dpack/

Mauro Venturini

unread,
Nov 17, 2004, 11:15:39 AM11/17/04
to
Sergey,
Ops, I assumed all assemblies were under
\WINNT\Microsoft.NET\Framework\v1.1.4322\
Microsoft.VisualStudio.dll is under \Program
Files\Microsoft.NET\SDK\v1.1\Bin\ that
is not referenced by default by D8.
Adding this folder to search paths the designer for services DO WORKS in D8
(both
for the D8 and RO samples).
The case for the installer designer seems different because not even the
designer surface
appears (while for the service it appeared with an error message). But I am
not sure
about the code of the installer, I have only a sample under the Demos folder
of D8.
Could you give me a working C#/VS installer sample?

"Sergey M" <no_spam_for_you> wrote in message
news:419b6a32$1...@newsgroups.borland.com...
> Mauro,

Sergey M

unread,
Nov 17, 2004, 11:26:42 AM11/17/04
to
Mauro,

> Ops, I assumed all assemblies were under
> \WINNT\Microsoft.NET\Framework\v1.1.4322\
> Microsoft.VisualStudio.dll is under \Program
> Files\Microsoft.NET\SDK\v1.1\Bin\ that
> is not referenced by default by D8.
> Adding this folder to search paths the designer for services DO WORKS
> in D8
> (both
> for the D8 and RO samples).

How do you add it to the IDE search path? More importantly, why would
you need to add it to the saerch path? The assembly is in GAC already
and that Desginer() attrubute on installer class already has full
assembly name listed.

BTW, check the readme.txt for that WinService sample on either D8 or
D2005 CD. That's my submission there <g>.

Mauro Venturini

unread,
Nov 17, 2004, 11:48:56 AM11/17/04
to
Sergey,
Microsoft.VisualStudio.dll is NOT in the GAC (at least it is not in my
machines
after a normal SDK installation, maybe VS does put it in).
I added the path in the Project-Options...-Directories/Conditionals and in
Component-Installed .NET Components...-Assemby Search Paths.

"Sergey M" <no_spam_for_you> wrote in message

news:419b7bc1$1...@newsgroups.borland.com...

Mauro Venturini

unread,
Nov 17, 2004, 3:38:51 PM11/17/04
to
I looked at your sample and the problem with installer designer seems related
to a missing (on my machines at least) EnvDTE.dll. Do you know something about it?

"Sergey M" <no_spam_for_you> wrote in message news:419b7bc1$1...@newsgroups.borland.com...
> Mauro,

Sergey M

unread,
Nov 17, 2004, 3:54:47 PM11/17/04
to
Mauro,

>I looked at your sample and the problem with installer designer seems
>related
> to a missing (on my machines at least) EnvDTE.dll. Do you know
> something about it?

Oh, yeah, I know that one all too well. EnvDTE.dll is used by VS.NET
automation model. That's what I've used for my DPack add-in collection.
EnvDTE.dll is in framework folder on my pc. I also have VS.NET installed
so that's what might have copied it there, but I'm not entirely sure. I
also see that EnvDTE.dll is in the GAC as well.

Mauro Venturini

unread,
Nov 17, 2004, 4:27:18 PM11/17/04
to
So at the end it is a VS dll missing from "normal" SDK. I'll try to get it somewhere...

"Sergey M" <no_spam_for_you> wrote in message news:419bba96$1...@newsgroups.borland.com...

Sergey M

unread,
Nov 17, 2004, 5:51:39 PM11/17/04
to
Mauro,

> So at the end it is a VS dll missing from "normal" SDK. I'll try to
> get it somewhere...

Not necessarily. I can think of at least three approaches they could've
taken: 1 - try to load designer assembly hoping that it's on the system,
2 - implement their own designer, 3 - take an easy way out and don't
show designer surface. Option 1 would've worked for me just nicely as I
have VS.NET 2003 installed on my pc. I would've liked the option 2 as
long as I had *some* sort of base design surface, just like the one
Component descendants get.

Mauro Venturini

unread,
Nov 17, 2004, 6:29:08 PM11/17/04
to
It seems I did not explain myself clearly enough. Let's try again.

Class System.ServiceProcess.ServiceBase
- The designers do works provided you tell Delphi where the assembly is (approach 1)
but the 'Add Installer' item of the designer pop up menu fails because it does not find
EnvDTE.dll (approach 1 I think, I need to find a copy of EnvDTE.dll to see if everithing
works when it is present).

Class System.Configuration.Install.Installer (as used in your sample, I could not generate
an installer using the designer due to the problem above)
- The designer surface does not show (not clear whether it is approach 3 or 1 again due to the
missing EnvDTE.dll).

Class System.ServiceProcess.ServiceInstaller and
class System.Service.ServiceInstaller
- The designers do works provided you tell Delphi where the assembly is (approach 1)

"Sergey M" <no_spam_for_you> wrote in message news:419bd5f9$1...@newsgroups.borland.com...

Sergey M

unread,
Nov 17, 2004, 6:58:53 PM11/17/04
to
> It seems I did not explain myself clearly enough. Let's try again.

Good info Mauro. I think we're getting somewhere. <g> I'll give it a
shot with D2005 and your configuration changes tomorrow night to see if
I can get it working. I'll also ask MS regarding EnvDTE.dll distribution
and will report back.

BTW, I think I recall either EnvDTE.dll or Microsoft.VisualStudio.dll
assembly having dependency on VSLangProj.dll, which is another VS.NET
extensibility interface assembly.

Sergey M

unread,
Nov 20, 2004, 9:23:38 PM11/20/04
to
Mauro,

I've reconsidered installing D2005 for now and am going to wait until
Borland decides to patch all of the IDE problems reported on these
newsgroups. I may have to report my designer findings at a later time.
I'll keep you posted.

Mauro Venturini

unread,
Nov 21, 2004, 3:44:44 AM11/21/04
to
Ok, thanks.
By the way I have just installed D2005 Architect Trial (here in Italy normal edition
will be available at the end of the mount) on my home PC (1GHz clock, 512 M ram,
W2K (no XP please), .NET SP1). It is reasonably (2 min) slow at loading (due to an
incredible number of packages) but the IDE is lighting fast and stable compared to D8
(and for speed even to D7).
I had none of the problems someone signalled (I suspect they are most related to XP SP2).
Adding \Program Files\Microsoft.NET\SDK\v1.1\Bin\ to Assemby Search Paths
I had the designers working as in D8.


"Sergey M" <n...@spam.com> wrote in message news:419ffbd1$1...@newsgroups.borland.com...

0 new messages