Just thinking...

[Alejandro Lapeyre]

Just thinking..

Why doesnt MSFT extend the .net as any other user would?
I mean, when they add something it comes as part of the new core.
Wouldnt it make sense it they released small classes that could be
added if you want?

For example, the windows.forms will be extended/replaced many times in
the future. Why does it have to be part of the core?

The new classes would come like the DirectX wrapper, something we
may install or not.

There are many usefull classes in the core that are hidden. For example
the control base class has a SendMessage function that is not accessible.
why?

Just thinking..

Best regards,
Alejandro Lapeyre

[Peter van der Goes]

"Alejandro Lapeyre" <Al**************@jotmail.com> wrote in message
news:ex**************@tk2msftngp13.phx.gbl...

Just thinking..

Why doesnt MSFT extend the .net as any other user would?
I mean, when they add something it comes as part of the new core.
Wouldnt it make sense it they released small classes that could be
added if you want?

For example, the windows.forms will be extended/replaced many times in
the future. Why does it have to be part of the core?

The new classes would come like the DirectX wrapper, something we
may install or not.

There are many usefull classes in the core that are hidden. For example
the control base class has a SendMessage function that is not accessible.
why?

Just thinking..

Best regards,
Alejandro Lapeyre

My take on this would be that there must be a standard functionality set for
the .NET framework so that any given developer's .NET product will find what
it needs on any target PC without having to worry if optional extras are
available. I guess I prefer knowing that my product developed with the .NET
Framework v1.1 is pretty much guaranteed to work on any target with .NET 1.1
installed. Allowing optional extensions and/or new versions of existing
classes to be installed at will kinda reminds me of DLL Hell days.
I'm sure there are other views, and I can't wait to hear them :)

--
Peter [MVP Visual Developer]
Jack of all trades, master of none.

[Alejandro Lapeyre]

Those would be installed just as your own dll's, in your project directory.

Best Regards,
Alejandro Lapeyre

"Peter van der Goes" <p_**********@toadstool.u> escribió en el mensaje
news:uM*************@TK2MSFTNGP12.phx.gbl...

"Alejandro Lapeyre" <Al**************@jotmail.com> wrote in message
news:ex**************@tk2msftngp13.phx.gbl...

Just thinking..

Why doesnt MSFT extend the .net as any other user would?
I mean, when they add something it comes as part of the new core.
Wouldnt it make sense it they released small classes that could be
added if you want?

For example, the windows.forms will be extended/replaced many times in
the future. Why does it have to be part of the core?

The new classes would come like the DirectX wrapper, something we
may install or not.

There are many usefull classes in the core that are hidden. For example
the control base class has a SendMessage function that is not accessible.
why?

Just thinking..

Best regards,
Alejandro Lapeyre

My take on this would be that there must be a standard functionality set
for the .NET framework so that any given developer's .NET product will
find what it needs on any target PC without having to worry if optional
extras are available. I guess I prefer knowing that my product developed
with the .NET Framework v1.1 is pretty much guaranteed to work on any
target with .NET 1.1 installed. Allowing optional extensions and/or new
versions of existing classes to be installed at will kinda reminds me of
DLL Hell days.
I'm sure there are other views, and I can't wait to hear them :)

--
Peter [MVP Visual Developer]
Jack of all trades, master of none.

[Peter van der Goes]

"Alejandro Lapeyre" <Al**************@jotmail.com> wrote in message
news:u2**************@TK2MSFTNGP10.phx.gbl...

Those would be installed just as your own dll's, in your project
directory.

Best Regards,
Alejandro Lapeyre

Right. Then I'd end up with multiple instances of the same (or, worse,
almost the same) DLL's scattered all over my drive as I installed more
products. Then, somebody would write the installer to put the DLL's in
....\Windows\System. If this sounds familiar, it should. As I said, DLL
Hell...

[Alejandro Lapeyre]

Do you see any pros?

Best Regards,
Alejandro Lapeyre

"Peter van der Goes" <p_**********@toadstool.u> escribió en el mensaje
news:OQ**************@TK2MSFTNGP15.phx.gbl...

"Alejandro Lapeyre" <Al**************@jotmail.com> wrote in message
news:u2**************@TK2MSFTNGP10.phx.gbl...

Those would be installed just as your own dll's, in your project
directory.

Best Regards,
Alejandro Lapeyre

Right. Then I'd end up with multiple instances of the same (or, worse,
almost the same) DLL's scattered all over my drive as I installed more
products. Then, somebody would write the installer to put the DLL's in
...\Windows\System. If this sounds familiar, it should. As I said, DLL
Hell...

[Nick Malik [Microsoft]]

Hi Peter,

DLL Hell was caused by two things: DLLs were expected to live in a common
directory, even if they would never be used in common, and
There was no consistent way to insure that every DLL was uniquely
identified.

Both of these flaws are fixed in .Net. In the current structure, dlls are
expected to live in your own directory. Any dll that you expect to share
MUST be signed in such a way as to insure that it comes from the same
source. All dlls include version numbers that should, ideally, uniquely
identify the library.

So with .Net, you shouldn't have the THREED.VBX problem that gave us all the
first real dose of DLL hell.

You did answer the question, though. In general, all developers want to
make sure that a system running the framework is running the same code as
another system running the framework. Having more than one "version" of
..Net framework 1.1, for example, would be a nightmare for deployment...
unless, as the OP suggests, the extensions are installed with the app.

As far as the notion of Microsoft releasing "extensions" to the framework
that can be included as DLLs in your own code...
Microsoft already does.

See
http://www.microsoft.com/resources/practices/code.mspx

All of these "extensions" are released by Microsoft with the intent that you
can use them in your own apps as long as your app installs them on the
target machine. They are also open source, which is nice because you can
see what they do.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Peter van der Goes" <p_**********@toadstool.u> wrote in message
news:OQ**************@TK2MSFTNGP15.phx.gbl...

"Alejandro Lapeyre" <Al**************@jotmail.com> wrote in message
news:u2**************@TK2MSFTNGP10.phx.gbl...

Those would be installed just as your own dll's, in your project
directory.

Best Regards,
Alejandro Lapeyre

Right. Then I'd end up with multiple instances of the same (or, worse,
almost the same) DLL's scattered all over my drive as I installed more
products. Then, somebody would write the installer to put the DLL's in
...\Windows\System. If this sounds familiar, it should. As I said, DLL
Hell...

[Peter van der Goes]

"Alejandro Lapeyre" <Al**************@jotmail.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Do you see any pros?

As a matter of fact, I do :)
*If it could be managed so as not to cause problems*, an up side would be
that improvements/new features would not have to wait for an official .NET
Framework release, right?
Anyway, take my opinions for what they are worth, and pay more attention to
folks like Nick, who is far more knowledgeable than I.