I have 2 versions of .NET, which is being used

[Lloyd Dupont]

My measurements show that for SQL Server 2005 Express there are 137

executable files (dll and exe) and of those 46 are managed. These are

common, 47 on 137, that's a good score for a huge legacy product!

 

[Lloyd Dupont]

You have ignored the PDC tech preview of Longhorn. There was a lot of .NET

in that build - a significant portion of the code that accessed your files
was implemented in .NET. In the next public build of Longhorn/Vista
Microsoft quietly removed that stuff.

that's indeed puzzling.
Me too I would like to know the nature of the problem, and their reason for
going back.

In any case, a 100% managed OS IMO would be a disaster, because .NET has
not been designed as a framework to write operating systems. However, you
can say the same about Win32. Device driver writers do not use Win32, they
use the DDK which is a totally different API.

Ever heard of Singularity?
http://research.microsoft.com/os/singularity/

I would like to hear more!
But realistically I won't as it is a competitor to windows....

 

[Scott M.]

- slower startup

It is. It's a fact of life. All the necessary runtime + user function are
JITted and verified and startup.
Write a simple C (or MFC) Form application and a simple .NET Winform app,
starts them on an old computer and you would see a difference.

All .NET apps can be pre-JIT-ted, if desired using NGEN.exe. .NET apps. do
not/are not slower in start up, period.

experience and fuzzy memory of previous reading.

May I suggest that you haven't accumulated enough .NET experience to make
these statements? Because each of these statements really has no merit.

IMHO

 

[Scott M.]

Many people are asking 'why should I upgrade to Vista'? You don't need to
upgrade to get WinFX (and the advantages of WPF and WCF - Avalon and
Indigo) so why not stay with XP? I guess the main 'upgrade' route will be
through new machines, because Microsoft will mandate that new Windows
machines will be Vista. So, as you say, it may take a long time for Vista
to be predominant.

This is not any different from when XP came out, or 2K before that. OS
upgrades/migrations typically come from OEM's first.

Microsoft has not abandoned new .NET applications at all. Where did
you get that from?

By looking at how many .NET applications Microsoft is producing, and how
much .NET there is in Vista. Vista may have .NET 2.0, but it does not have
WinFX. We are told that WPF and WCF will revolutionize the way that
applications will be written, but Microsoft are not using those
technologies themselves. What does that say to you? To me that says that
there are two camps in Microsoft - those pushing .NET and those resisting
it. The former were in charge at the time of the PDC 2003 technical
preview of Longhorn, the latter are in charge now.

Vista [formerly Longhorn] has been in development
since .NET was. It makes no sense to tear down your next major OS
just to incorporate your new development platform, just as you won't
see Office re-written as .NET applications because of the millions of
lines of non-managed code that is in it.

You have ignored the PDC tech preview of Longhorn. There was a lot of .NET
in that build - a significant portion of the code that accessed your files
was implemented in .NET. In the next public build of Longhorn/Vista
Microsoft quietly removed that stuff.

Much of the promised file system features were eliminated because of the
difficulty level in making it work reliably and securly. Since the OS is
not managed itself, there shouldn't be any reason that MS *must* stuff .NET
into it.

In any case, a 100% managed OS IMO would be a disaster, because .NET has

not been designed as a framework to write operating systems. However, you
can say the same about Win32. Device driver writers do not use Win32, they
use the DDK which is a totally different API.

There is no reason at all to believe that *brand new* MS applications
[again: down the line] won't be written in 100% managed code.

Hmmm, so Microsoft decides that they want some anti-spyware as part of
Windows. What do they do? Well they buy up a product that was written in
unmanaged VB and they port that code. Don't you think that would be a good
opportunity to rewrite the code as managed code? (Heck, they could even
use the VB porting tool that they tell their customers to use <g>). No,
they didn't do that, instead they rewrote it as unmanaged C++. What does
that say?

But this isn't what I'm talking about at all. I'm talking about brand new
applications *written* from the ground up. Purchasing a 3rd party product
and re-writing it as unmanaged code just fits into what I've been saying in
the first place - - today MS can't guarantee that all Windows OS's out there
have .NET on them, so most code is unmanaged. It won't be until the .NET
Framework is standard on most machines out there for you to see apps.
written in .NET hit the mainstream.

 

[Willy Denoyette [MVP]]

common, 47 on 137, that's a good score for a huge legacy product!

But these have nothing to do with SQL "Server" code, it's supporting code
for interop and client side management, you don't need this stuff if you
only run SQL server without using CLR stored procs.
Also note that even when hosting the CLR, SQL Server will not use all of the
functionality of the CLR. SQL server uses the CLR GC to manage object
lifetime, but he allocates/manages his own GC heap, the same goes for
threading, SQL uses it's own thread pool, and you aren't allowed to start a
thread in a managed stored procedure when hosting, neither can you use
PInvoke interop.

Willy.

 

[Willy Denoyette [MVP]]

Michael D. Ober wrote:

dumpbin /clrheader is your friend. If the file is a .NET assembly the
/clrheader will list details about .NET in that file; if it is an
unmanaged application, then /clrheader will not list anything. You can
also use the tool on my website which will go through a folder and tell
you which files are managed, which are unmanaged and which are managed but
host the runtime.


No it isn't. SQL Server 2005 hosts the runtime to allow you to write
stored procedures in .NET. This means that it is an unmanaged application
that allows .NET code to run in its memory.

My measurements show that for SQL Server 2005 Express there are 137
executable files (dll and exe) and of those 46 are managed. These are for
interop with managed code, for ASP.NET, but the majority are for 'setup
bootstrap'. All of the main files in SQL Server are unmanaged. So it is
incorrect to say that SQL Server is a .NET application.

Did you also notice that a number of "SQL assemblies" are now authored using
C++/CLI? Is this just "dog-fooding" or is there something else going on?

Willy.

 

[Lloyd Dupont]

May I suggest that you haven't accumulated enough .NET experience to make

these statements? Because each of these statements really has no merit.

You could always suggest, but I don't believe you.

 

[Guest]

It is. It's a fact of life. All the necessary runtime + user function are
JITted and verified and startup.

They're JITed only the first time they run, correct?

 

[Lau Lei Cheong]

Please let me add that in fact, the indicator for my company to see whether
..NET is ready to be used to develop "general public application" is if there
is MS Office version released that uses it. Because by then we can be safely
assured that most commercial users already have .NET framework installed and
the "big runtime" will no longer be a real drawback. (I think it's
reasonable to assume user will feel OK to install the runtime with any
100MB+ essential application, but they won't feel good when need to install
the 23.1MB runtime in order to run a < 1MB one)

 

[Richard Grimes]

That doesn't address your concern that there are so few .NET based
app on Vista.
Well I don't know...
Maybe you should ask them, I believe you sometimes go at redmond?

I have, but I am not saying the answer I got, but it wasn't encouraging

Or ask Paul Thurot if you know him?

Nope, I've never met him and he doesn't reply to my emails.

However since even my elder sister got a computer powerfull enough to
run all the app
I wan to show her without problem, I came to believe that every
computer is powerfull
enough nowadays.

hah ha, perhaps she would like to swap with one of mine, I could do with
a faster machine ;-)

The problem is that when you have an organization with lots of machines
getting them all up to spec is costly. Even if that means putting in
just $50 of memory, you have to factor in the downtime of the machine
and the cost of the engineer to install the memory.

In fact you have to download it... However:
- We are using eSellerate to sell off the web, and they could send
you a CD. - We have many resellers, some of them are such shop. but I
don't
know the exact reseller list.

It would be interesting to see how it sells. If you sell it via CD then
installing the framework is a no brainer. However, it would be
interesting to see how your customers who download it will react to the
indication that they need to download another 25Mb from Microsoft.

Don't repeat it, and don't tell anyone I told you, but I think
(Java's) Swing is, too,
far superior to Winform.

Richard

 

[Richard Grimes]

Ever heard of Singularity?
http://research.microsoft.com/os/singularity/
yes.

I would like to hear more!
But realistically I won't as it is a competitor to windows....

Not for a long, long while.

When Java came out there was a gret buzz about a 'Java OS', even chips
that would run Java bytecode...

Richard

 

[Jon Skeet [C# MVP]]

They're JITed only the first time they run, correct?

No - unless you ngen them, they are JITted every time they run.
However, each method is only JITted the first time it's run. In other
words, the JITted code is used for the process lifetime, but then
thrown away (if you don't use ngen).

 

[Lloyd Dupont]

I have, but I am not saying the answer I got, but it wasn't encouraging
<g>

Now that's scary man!
(I'm also very curious now... was it some kind of not to be disclosed
answer?)
(Was it some scary answer which truthfulness will diminish with each new
release/improvment of the .NET runtime?)

It would be interesting to see how it sells. If you sell it via CD then
installing the framework is a no brainer. However, it would be interesting
to see how your customers who download it will react to the indication
that they need to download another 25Mb from Microsoft.

So far, early adopters (bug reporters/alpha testers) didn't even think to
complain.
They just reported my bugs
But that's the early adopters!

 

[Scott M.]

John, can you provide more detail on this? To my knowledge, once the
initial JIT happens, the IL assembly is compiled down to native code, which
is then stored (ASP.NET) in the
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files folder
and remains there until/unless the IL assembly is modified, at which time a
new JIT assembly is created. So, once the assembly is JIT-ted, it will not
be re-JIT-ted unless the IL assembly changes.

 

[Scott M.]

Your statements have been made without any technical explanations and
according to you, you have fuzzy memory of what you've read and you haven't
provided any details on what experience you have in these areas.

My knowledge and 4+ years of experience tell me that you are just making
baseless statements. Until you can provide any facts for your position, how
can we take your position seriously?

Every item you mentioned, I have provided a rebuttal to. Your response is:
"I don't belive you."? Ok, good luck to you.

LOL

 

[Scott M.]

Office 2003 does support .NET integration, but why in the world would you
expect MS to re-write millions of lines of COM code to .NET code? Office
already works. It would be cost-inefficent to re-write it.

 

[Lau Lei Cheong]

Don't ask me. It's the management. XD

I think they may think that Microsoft will use Office to demo the power of
..NET framework, just like what they did for Office 95...

But I think it's not impossible, just quite unlikely. Afterall, they did
attempt to rewrite the OS with as much managed code as possible...

 

[Lloyd Dupont]

Your statements have been made without any technical explanations and

according to you, you have fuzzy memory of what you've read and you
haven't provided any details on what experience you have in these areas.

I didn't intend to prove it.
I search 2 minute and though "oh well".... let's drop it politely (by
answering I have fuzzy memory)

My knowledge and 4+ years of experience tell me that you are just making

Well, I could reply I have 8 year of experience (including 4 years .NET) and
I'm not impressed.

baseless statements. Until you can provide any facts for your position,
how can we take your position seriously?

Please, go on, proves yours.
I don't care much, I was sharing an accumulated impression.

You did disagree me but I found you to too bully and blindly affirmative to
convince me.
You might be right, that would be cool.
But I would rely on more convincing people to make me change my opinion.
Or my own experience, curiously my program start quite fast lately, but I
wonder if it's .NET 2.0 or my computer, or both.


To pleases you I decided to argument a bit more here, to gives you an
opportunity to convince me as, I feel, you boil to do.
3 facts:
- in 2001 I clearly remember it tooks about 1 second to launch an empty
WinForm whereas Notepad was already instantaneous. Since then it has
improved. Truth to tell it has been a while I didn't experience slow
startup, but I'm not yet convince 100%.
- I read once in some MS newsgroup a complaint from an ASP develop which has
server with 3GB of memory and was previously able (through some extension
API I can't remember of) to use most of it in plain C program.
In .NET he was somehow limited to much less (maybe 1.3Gb) and it was some
problem due to .NET.

 

[Jon Skeet [C# MVP]]

John, can you provide more detail on this? To my knowledge, once the
initial JIT happens, the IL assembly is compiled down to native code, which
is then stored (ASP.NET) in the
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files folder
and remains there until/unless the IL assembly is modified, at which time a
new JIT assembly is created. So, once the assembly is JIT-ted, it will not
be re-JIT-ted unless the IL assembly changes.

That's true for ASP.NET (although I dare say the directory may be
cleaned out every so often).

I see no indication that this thread is only about ASP.NET though.

 

[Willy Denoyette [MVP]]

Don't ask me. It's the management. XD

I think they may think that Microsoft will use Office to demo the power of
.NET framework, just like what they did for Office 95...

But I think it's not impossible, just quite unlikely. Afterall, they did
attempt to rewrite the OS with as much managed code as possible...

Really? what part of the OS?

Willy.