Purpose of sectionGroup's "type" attribute in "web.config"

[JG]

Hi,

Can someone explain what the "type" attribute is used for in "web.config"
when applied explicitly to the "sectionGroup" tag. I'd like to know if I
should be using this for anything when creating wrapper classes for my own
custom sections. In particular, all the examples I can find on the web
discuss how to create a class for the "section" tag but this is based on
that tag's "type" attribute. So what if anything should I use the "type"
attribute for when dealing with the "sectionGroup" itself. Thanks very much.

 

[Gregory A. Beamer]

Hi,

Can someone explain what the "type" attribute is used for in
"web.config" when applied explicitly to the "sectionGroup" tag. I'd
like to know if I should be using this for anything when creating
wrapper classes for my own custom sections. In particular, all the
examples I can find on the web discuss how to create a class for the
"section" tag but this is based on that tag's "type" attribute. So
what if anything should I use the "type" attribute for when dealing
with the "sectionGroup" itself. Thanks very much.

Teh documentation spells it out rather nicely:
http://msdn.microsoft.com/en-us/library/ms228114.aspx

the example in the help file is setting up an authentication section
inside a web section group (in essence).

The type leads you back to the code that actually runs.Hope this helps.

Peace and Grace,

 

[JG]

Teh documentation spells it out rather nicely:

http://msdn.microsoft.com/en-us/library/ms228114.aspx

the example in the help file is setting up an authentication section
inside a web section group (in essence).

The type leads you back to the code that actually runs.Hope this helps.

Thanks. I already looked at that previously (first order of business) but it
doesn't clearly spell out how it relates back to code. The standard
technique you find in all examples is to set the "section" tag's "type"
attribute to a "ConfigurationSection" derivative. You then mark each
property of that derivative with the "ConfigurationPropertyAttribute" and
the property then corresponds to the individual "section" attributes. No
examples I can find spell out how the "sectionGroup" tag's "type" attribute
is supposed to be used however. None of the examples even declare this
attribute (just the "sectionGroup" tag only). I could experiment and
probably figure it out (I think I know it works intuitively) but I'd like
to see something more official. Any ideas? Thanks again.

 

[Gregory A. Beamer]

Thanks. I already looked at that previously (first order of business)
but it doesn't clearly spell out how it relates back to code. The
standard technique you find in all examples is to set the "section"
tag's "type" attribute to a "ConfigurationSection" derivative. You
then mark each property of that derivative with the
"ConfigurationPropertyAttribute" and the property then corresponds to
the individual "section" attributes. No examples I can find spell out
how the "sectionGroup" tag's "type" attribute is supposed to be used
however. None of the examples even declare this attribute (just the
"sectionGroup" tag only). I could experiment and probably figure it
out (I think I know it works intuitively) but I'd like to see
something more official. Any ideas? Thanks again.

This is big problem with the config file. Since so many of the built in
tools can "edit" it for you, connection strings and app settings get all
of the attention.

Type is specified by {class name}, {assembly}, so it is a pointer to the
class that handles the section and indicates which assembly to look at.
The assembly needs to be referenced, as well.

The full signature is {class name}, {assembly}, {version}, {culture},
{public key token}. The full signature can paint you in a box if you
don't know what you are doing, but does allow for you to set up an app
that will only use a specific version, which can be useful in some
instances.

My suggestion is find an open source project that uses section group and
play with it. You will gain far more understanding than anything someone
can teach you in a newsgroup.

Peace and Grace,

 

[JG]

This is big problem with the config file. Since so many of the built in

tools can "edit" it for you, connection strings and app settings get all
of the attention.

Type is specified by {class name}, {assembly}, so it is a pointer to the
class that handles the section and indicates which assembly to look at.
The assembly needs to be referenced, as well.

The full signature is {class name}, {assembly}, {version}, {culture},
{public key token}. The full signature can paint you in a box if you
don't know what you are doing, but does allow for you to set up an app
that will only use a specific version, which can be useful in some
instances.

My suggestion is find an open source project that uses section group and
play with it. You will gain far more understanding than anything someone
can teach you in a newsgroup.

Actually, I'm very familiar with the details of qualified assembly names
having done some deep reflection work. The problem is that I can't find any
examples of how this type is used in code when applied to a section group.
It's easy enough to define this class (its qualified name in "web.config"
and the corresponding class in code), it's another thing to determine what
the official protocol is for using it. That's what I can't figure out.
There's a protocol in place for the "section" tag itself but I can't find
anything that addresses the section group.

 

[Gregory A. Beamer]

Actually, I'm very familiar with the details of qualified assembly
names having done some deep reflection work. The problem is that I
can't find any examples of how this type is used in code when applied
to a section group. It's easy enough to define this class (its
qualified name in "web.config" and the corresponding class in code),
it's another thing to determine what the official protocol is for
using it. That's what I can't figure out. There's a protocol in place
for the "section" tag itself but I can't find anything that addresses
the section group.

I've got this on my "look this up and see if you can find an easy
tutorial" list, but I can't guarantee anything real quick, as I have a site
to deploy really soon.

 

[JG]

Actually, I'm very familiar with the details of qualified assembly

I've got this on my "look this up and see if you can find an easy
tutorial" list, but I can't guarantee anything real quick, as I have a
site
to deploy really soon.

Ok, thanks. Hope you have better luck than I've had so far. I'm sure if I do
more digging I can eventually find something but honestly, I don't have the
time for it either. That's not to say I'm depending on you or others to do
my work for me (I don't work that way). However, since moving to .NET 3+
years ago after many years of C++, I'm astounded by the countless number of
hours I've had to spend digging for information like this (hundreds -
literally).

 

[Gregory A. Beamer]

Ok, thanks. Hope you have better luck than I've had so far. I'm sure
if I do more digging I can eventually find something but honestly, I
don't have the time for it either. That's not to say I'm depending on
you or others to do my work for me (I don't work that way). However,
since moving to .NET 3+ years ago after many years of C++, I'm
astounded by the countless number of hours I've had to spend digging
for information like this (hundreds - literally).

I have heard it stated that the new direction of IDE will lead to more
research and less time developing. The tools will be faster, but you
have a learning curve. I guess this proves it to be true.

 

[JG]

I have heard it stated that the new direction of IDE will lead to more

research and less time developing. The tools will be faster, but you
have a learning curve. I guess this proves it to be true.

It's primarily due to the never-ending glut of technology coming from MSFT's
R&D labs. Nothing is ever around long enough to become stable. There's far
too much of it (I'm being kind), and they're in constant violation of the 1%
rule (building huge amounts of functionality that cater to only 1% of the
development community - the other 99% are left to drown in a sea of
technology). For all their efforts, the environment is more unstable than
I've ever seen after 25 years on their platforms. A day now rarely ever goes
by where I'm not cursing them (after being a staunch supporter for most of
my career - that support has been in serious decline for several years now).

 

[Gregory A. Beamer]

It's primarily due to the never-ending glut of technology coming from
MSFT's R&D labs. Nothing is ever around long enough to become stable.
There's far too much of it (I'm being kind), and they're in constant
violation of the 1% rule (building huge amounts of functionality that
cater to only 1% of the development community - the other 99% are left
to drown in a sea of technology). For all their efforts, the
environment is more unstable than I've ever seen after 25 years on
their platforms. A day now rarely ever goes by where I'm not cursing
them (after being a staunch supporter for most of my career - that
support has been in serious decline for several years now).

I am not quite to the point you are, but the pace of technology has been
rather fast. This is partially due to competition from both Adobe (Flex,
etc.) and Google (search engine to start, but moving in other fronts).
There is also a component that goes along with Developer & Tools
division calling a lot of the shots, esp. the ASP.NET guys (who are
typically far more Agile).

I have expressed my concerns, as have many other MVPs and leaders. I
have seen, for example, articles by Kathleen Dollard, Billy Hollis,
Rocky Lhotka, and others, lamenting the pace of technology.

In just the past couple of years, we have seen the following
technologies either spring up or get pushed forward with new MS
offerings:

WPF - XAML
WCF
WF
WPF/E, which became
Silverlight 1-3
ASP.NET AJAX
ASP.NET MVC
LINQ
Entity Framework
Azure
SharePoint
Team Foundation Server
Generics
Web Applications
Unit Testing Frameworks
Unity (IoC container)
Dynamic Data
Expression Suite
Media Encoders
Functional Languages (F# in particular)
Deep Zoom
Anonymouse Methods and types
CLR and HTTP endpoints in SQL Server
new SQL types

And this does not touch changes in OS, Office, etc.

I am sure I am missing quite a few in the mix, but each of these were
released with VS 2005 or later, which means the last five years, with
many in just the last year and a half. And there is more coming (MEF,
heavier SharePoint integration, more anonymous bits, M (and its various
tools), etc). And some ideas have died out.

Microsoft has, however, provided a lot of information. And, in their
favor, they have gotten it to where devs are not writing a lot of
plumbing code. On the negative side, there are some interesting bugs in
Windows 7 that are a bit concerning. And IE8 routinely crashes, at least
on Win 7, but it recovers, so it is a mixed bag.

I am not against the technology, so much, as against the technology
outpacing the tools by such a wide swath. When the tools catch up, the
community can really embrace things. Until then, they are throwing a lot
of things for the bleeding edgers to get cut on.

I will turn rant off for now. ;-)

Peace and Grace,

 

[JG]

It's primarily due to the never-ending glut of technology coming from
Your laundry list of technologies helps reinforce my point. I can cite
others from years gone by including COM (still underpinning many things)
which never had proper tools (ATL was all there was outside of VB and an
aging MFC and you had to be Stroustrup himself to understand some of it). In
any case, the software coming from MSFT in the past 5 years has been more
unstable than anything I've ever experienced as a developer. Far more than
anything that came before the days of .NET. I can't begin to tell you the
number of problems I've had. Hundreds (probably into the thousands now) of
hours wasted dealing with a never-ending torrent of problems. I've reported
many of them to MSFT itself, some even making it into their SPs, but far
more have gone unreported. Almost everything I now touch seems to have some
problem with it (at some point or another). Tools not working as documented.
documentation not correct as documented (and often woefully lacking in
info), flaky, unstable or outright broken behaviour with so many things I
use. There are constant crashes, freeze-ups, exceptions, bugs and so forth
in so many things now that I've really stopped forgiving it, something I was
quick to do in the past (because I know as an experienced developer how hard
it is to get things right). MSFT does a lot of very good things but whatever
the reason is, whether it be too much "stuff" being shoved out the front
door in Redmond before it's ready, or cutbacks to the quality of their staff
and their QA dep't (probably a mixture of all of the above), something is
seriously wrong there these days.

 

[Gregory A. Beamer]

Your laundry list of technologies helps reinforce my point. I can
cite others from years gone by including COM (still underpinning many
things) which never had proper tools (ATL was all there was outside of
VB and an aging MFC and you had to be Stroustrup himself to understand
some of it). In any case, the software coming from MSFT in the past 5
years has been more unstable than anything I've ever experienced as a
developer. Far more than anything that came before the days of .NET. I
can't begin to tell you the number of problems I've had. Hundreds
(probably into the thousands now) of hours wasted dealing with a
never-ending torrent of problems. I've reported many of them to MSFT
itself, some even making it into their SPs, but far more have gone
unreported. Almost everything I now touch seems to have some problem
with it (at some point or another). Tools not working as documented.
documentation not correct as documented (and often woefully lacking in
info), flaky, unstable or outright broken behaviour with so many
things I use. There are constant crashes, freeze-ups, exceptions, bugs
and so forth in so many things now that I've really stopped forgiving
it, something I was quick to do in the past (because I know as an
experienced developer how hard it is to get things right). MSFT does a
lot of very good things but whatever the reason is, whether it be too
much "stuff" being shoved out the front door in Redmond before it's
ready, or cutbacks to the quality of their staff and their QA dep't
(probably a mixture of all of the above), something is seriously wrong
there these days.

I disagree to an extent, as the QA department is rather large. If you
keep up with technology, you will generally find the stuff works
together. it is mixing of stuff from today and stuff from 2 to 3 years
ago that leads to most of the problems. Many of the issues now are VS
2008 on Windows XP (or older). The same is often true when using old
versions of Visual Studio with newer OS version.

I imagine a heavy push to Windows 7 when it comes out, as it will reduce
the pain points when used with the latest versions.

The problem is there are too many variables to adequately test
everything. Blue screens are most often caused by hardware drivers. And,
many of the BSODs I have seen on my own equipment are trying to use
Windows Vista or Windows 7 on a machine originally slated for Windows
XP.

Essentially, the fringe conditions are not being adequately tested, and
the number of fringe cases are increasing as more and more new hardware
and software comes out.

On the positive side, Microsoft has a lot of good material out there
(although some are a bit peeved that blogs have newer/better information
than the MSDN site - and you can more easily search it with Google than
Live Search ... er, Bing (which may not be true now)). ;-)

Peace and Grace,

 

[JG]

I disagree to an extent, as the QA department is rather large. If you

keep up with technology, you will generally find the stuff works
together. it is mixing of stuff from today and stuff from 2 to 3 years
ago that leads to most of the problems. Many of the issues now are VS
2008 on Windows XP (or older). The same is often true when using old
versions of Visual Studio with newer OS version.

That's inaccurate. I can cite countless mainstream problems. A random
selection which only scratches the surface (I've got a very large list):

1) IE8 randomly freezes (what version of IE hasn't)
2) SourceSafe (VSS) - Can't check in our (test) SQL Server Express DB (.mdf
file) to the remote VSS server, probably due to its size (we're guessing at
this point - it's a measly 7 Meg only however). Frequent failures trying to
check in any file to the remote server in general however (server is stable
outside of VSS). Auto-generated files like "MyDataSet.Designer.cs" in Visual
Studio can also wreak havoc with VSS - it thinks the file is being deleted,
prompts to remove the file either locally or on the VSS server itself (you
don't want either), and then deletes it anyway after clicking *Cancel*.
There are other problems as well.
3) Virtual PC freezes up when using IE especially (but is effectively
unusable with IE because it's so slow - performance for Vista makes it a
write-off altogether - it barely moves and I'm on a fast machine). VMware is
much faster and stable on the same machine
4 "aspnet_regiss.exe" may generate "A configuration file could not be
created for the configuration object" error when trying to run it with
the -pe and -app option (references to this all over the net)
5) .NET form applications can't be debugged on a background worker thread (a
very serious and frustrating problem). This is a acknowledge by MSFT (with
some woeful work-arounds that barely do anything)
6 "Server Application Unavailable" error frequently occurs when setting up
an IIS app for the first time. The fix typically involves a series of steps
that take a lot of digging to figure out (I have those steps which can
include everything from shutting IIS and ASP.NET down and re-starting, to
ensuring proper permissions are set up for various accounts on various
folders - ASPNET account on XP, Network Service account on later versions of
Windows - IUSR_MACHINENAME where appropriate, etc. - Various folders may be
involved such as the ASP.NET temporary folder
("C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files".
for instance), "C:\Documents and Settings\<ComputerName>\ASPNET\Local
Settings\Temp", etc. You usually need advance IIS, ASP.NET and Windows
security knowledge in general to repair these issues (ridiculous)
7 "DataGridView" control (a major control) has significant bugs (I can show
you them), is *extremely* slow after just a few hundred rows or less
(especially when wrapping is req'd), is unbelievably difficult to master
(when you need more fine-grained control but nothing out of the ordinary),
and is lacking some major (very basic) functionality (try scrolling away
from the current row and bringing it back into view programatically)
8 "Path.GetDirectoyName()" throws an "ArgumentException" if an empty string
is passed. Docs used to claim it returns null but the last version I checked
says that *both* will occur (Return value conflicts with the Exceptions
section). I have many such examples of incorrect, sloppy, or woefully
inusffiicient documentation.
9 Windows Live Messenger *consistently* crashes when I try to use the VoIP
feature (no problems using other VoIP packages like Skype)
10) See here
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=288970
and here
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=278081
and here
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=143128
and here
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=314567
and here
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=410633
(and so on - bugs and issues I've reported)

Almost every day (no exagerration) I experience problems just like this and
many more. It's been like this almost since day one after leaving the C++
world to work with C# and .NET (about 4 years ago). It's cost a huge amount
of time, money and frustration. I can only reiiterate the obvious, there's a
serious problem at MSFT these days (precious little to do with incompatible
mixtures of old and new technology).

 

[Gregory A. Beamer]

That's inaccurate. I can cite countless mainstream problems. A random
selection which only scratches the surface (I've got a very large
list):

Which was why I said "to an extent". There is still a huge issue with
1.0 releases, which many of the products you mention are. And
SourceSafe, in my opinion, has all but been scrapped.

As a personal note, I am using SourceSafe at work (albeit with VS 2005),
but all of my new work is either with TFS or an open source source
control (SVN primarily), as SourceSafe is just getting farther and
farther away from the dev tools.

I still find when you are playing with all of the newest stuff, you have
far fewer issues. IE8 is a definite exception, however, as it breaks
routinely.

Peace and Grace,