...
I have a thread going on a similar problem in
microsoft.public.frontpage.client with Subject =
WebPartPages

ataViewWebPart
Did your solution seem to fix errors of this type as well? I have been
fortunate to get a MS tech to help me out on it...feel free to reply to
group or me for more details.
Derek,
Yes, everything is working well. I read your thread in frontpage.client and
I think I have an explanation for you.
After reading the KB article it occurred to me that all of my virtual
servers are assigned an IP address with the exception of the default server,
which is set to *all unassigned addresses*. Even though the default server
is not extended, it would seem that .NET thinks it's the root for any
SharePoint extended site, most likely because it's the only one not tied to
a particular address.
This is an ideal situation for me because I also have many FrontPage 2002
extended virtual servers running .NET applications, and I was concerned
about interactions between the two. I want to be able to install and
register WebParts for all SharePoint sites simultaneously, and from what
I've read here, it appears that I can set up my individual .NET applications
as usual, with assemblies located in the bin folder and configuration files
in the root, while at the same time I can add my SharePoint WebParts and
configuration files to the default sever for all the SharePoint sites.
I'm assumming that the Microsoft.SharePoint assembly is installed in the
GAC, but if .NET searches the default Web site root folder for a web.config
file for *any* SharePoint site, I'm hoping it will also look in the default
server's \bin folder for WebPart assemblies. That means single folder
configuration and assembly deployment without screwing around with strong
names and the GAC.
As soon as I finish developing my first WebPart control and deploying it,
I'll report in here with the results. I suppose we can leave it to Microsoft
or the MVP's to discover whether there's a downside to doing it this way,
and specifically with regard to security issues.
I copied my original post below for the benefit of any frontpage.client
subscribers interested in this subject.
--
Regards,
Fred Chateau
e-mail: fchateauAtHotelMotelNowDotCom
--
After installing WSS and extending several virtual servers, I discovered
that all Web Part controls were returning the error message "Not registered
as safe", although each extended virtual server root contained a web.config
file. After several hours of working on this problem, I decided to place a
copy of one of the web.config files which SharePoint had installed, into the
default Web server's root folder. Since I hadn't extended the default
server, there was no web.config file located there. To my surprise, the Web
Part controls started working in all the extended virtual servers.
So my question is what's going on here? In retrospect, it makes some sense
to me. Although the ASP.NET script maps appear separately in IIS Manager, I
believe they are also inherited from the default server, but if the
web.config file is being inherited, why does SharePoint install one in each
virtual server?
Also, should I assume the other unmanaged folders and files that SharePoint
installs are similarly inherited?