Just thinking...

  • Thread starter Thread starter Alejandro Lapeyre
  • Start date Start date
A

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
 
Alejandro Lapeyre said:
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
Click to expand...
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 :)
 
Those would be installed just as your own dll's, in your project directory.

Best Regards,
Alejandro Lapeyre
 
Alejandro Lapeyre said:
Those would be installed just as your own dll's, in your project
directory.

Best Regards,
Alejandro Lapeyre
Click to expand...
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...
 
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.
--
 
Alejandro Lapeyre said:
Do you see any pros?
Click to expand...
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.
 
Back
Top