.NET Framework

[macman87]

When you programme with Visual Studio .NET your application needs the .Net framework to run. How can i make a application less than 2 MB of size using the .NET framework? :wacko:

[smurfiness]

No, it doesn't. But I've seen several hundred email addresses flash over my screen since 1.0 came out, so that's not a surprise. *L*

--

Danny Smurf

[MikeStammer]

No problem. When 1.0 came out I tried it and emailed asking for proxy support. I thought it was odd that we should meet up at this board and discuss the same subject again. Small world!

[.Atlantis]

This .NET Framework will be a pain in the A$$ at first, just like any update that needs bringing into the Windows Community, all Microsoft are trying to do is get it out to almost everyone in the world who owns a Microsoft PC. So soon everyone will have .NET Framework. Of course it's going to be a rough ride at first. Just like anything else ?_?

[smurfiness]

This .NET Framework will be a pain in the A$$ at first, just like any update that needs bringing into the Windows Community, all Microsoft are trying to do is get it out to almost everyone in the world who owns a Microsoft PC. So soon everyone will have .NET Framework. Of course it's going to be a rough ride at first. Just like anything else ?_?

Quite true. Aside from the whole getting users to download it thing, there are other pains that go with .NET for the time being.

For one thing, it's not QUITE as Windows version-neutral as Microsoft would like everyone to believe. Some of my users using XP Home have had some significant problems with .NET code that runs perfectly fine on XP Pro.

And for another, there are a lot of really weird crashing bugs that pop up for no particular reason. For example, changing a selection in a list view will always throw an ArgumentOutOfRangeException. There's nothing actually wrong (you can catch the exception and discard it, and everything will work as it should), but it will still crash the app.

Once the minor stuff like that gets worked out, .NET will be a lot less painful.

--

Danny Smurf

[.Atlantis]

Danny, thats also quite true. But what I think Microsoft is trying to do, is get programmers to start getting used to the .NET functionality and the way .NET works, all for the release of Longhorn. Which I'm pretty sure will be using .NET Framework in it's coding. So I guess what Microsoft are trying to do is say "Get ready, look at whats coming"

[MikeStammer]

I KNOW that Longhorn's version of Explorer.exe is a .NET app. Play with the latest build and when it crashes, an unhandled .NET exception is displayed. Cool!

[dacris2000]

I KNOW that Longhorn's version of Explorer.exe is a .NET app. Play with the latest build and when it crashes, an unhandled .NET exception is displayed. Cool!

I think that's just the CLR debugger that has been integrated along with the normal JIT debugger. Try crashing another normal Win32 app and see if the same message appears as for the Explorer crash.

[.Atlantis]

I think longhorn is just an XP makeover right now, not hardly enough code to call it a .NET OS

[NXPdev]

I KNOW that Longhorn's version of Explorer.exe is a .NET app. Play with the latest build and when it crashes, an unhandled .NET exception is displayed. Cool!

Well, my suspicion is that explorer.exe is still same C++ code just with the "Use Managed Extensions for C++" option ticked on build... or maybe I'm totally wrong!

[session]

maybe they use flash to write explorer.exe :p naw im just being dumb!!! but hey, what is real :p .net of non-.net, it's all about choice! :p

[NXPdev]

I think longhorn is just an XP makeover right now, not hardly enough code to call it a .NET OS

It hardly has any managed code... to be a .NET OS, it should have at least 50%+ managed code... which it clearly doesn't.

But, we still see some shipping Microsoft apps with managed code- eg UUDI, XP Media Center, the Outlook BCM... which is pretty encouraging. And since WinFS is supposed to be based on Yukon, which is supposed to use .NET v2.0, then maybe WinFS will be written in managed code too!

[smurfiness]

It hardly has any managed code... to be a .NET OS, it should have at least 50%+ managed code... which it clearly doesn't.

YET.

Don't forget, it's not even in the beta stage yet. And we don't know how much managed code is really in there. It may just have "the "Use Managed Extensions for C++" option ticked on build," but that would indeed make it managed code, since that will compile it to run on the .NET Framework. And that's all it takes to make a lot of programs managed. We have no idea how much of that Microsoft has done.

--

Danny Smurf

[NXPdev]

Having that option ticked doesn't mean it is managed code - it could see be using traditional C++, and not taking any advantages of the Managed Extensions.

[azcodemonkey]

And for another, there are a lot of really weird crashing bugs that pop up for no particular reason. For example, changing a selection in a list view will always throw an ArgumentOutOfRangeException. There's nothing actually wrong (you can catch the exception and discard it, and everything will work as it should), but it will still crash the app.

Hey Danny Smurf,

I read your post and checked out that behavior. The reason you're getting that exception is because the list view item that is being deselected is firing the event, as well as the item that is being selected. Just test the SelectedIndices.Count before you do anything.

private void listView1_SelectedIndexChanged(object sender, System.EventArgs e)
{
    if( listView1.SelectedIndices.Count < 1 )
        return;
    // other code

That is probably expected behavior since the event is firing when the index changes, just once for each item being selected and deselected.

Cheers!

[smurfiness]

Having that option ticked doesn't mean it is managed code - it could see be using traditional C++, and not taking any advantages of the Managed Extensions.

It doesn't matter if it's written in "traditional" or not. Ticking that option compiles it to run on the Framework. The language it was actually written in is irrelevant. Managed code is "managed" because the CLR "manages" its execution.

--

Danny Smurf

[smurfiness]

I read your post and checked out that behavior. The reason you're getting that exception is because the list view item that is being deselected is firing the event, as well as the item that is being selected. Just test the SelectedIndices.Count before you do anything.

Thanks for that. That's... rather odd behaviour. I'd think that the event should only fire once, since the selected index is only changing once (one unselect + one select = one change). I'll give that code you posted a try. Thanks. :)

--

Danny Smurf

[NeoMayhem]

how many people actally have the framework? I mean it wasn't in windows xp but it came on on xp SP1 and it wasn't on windows 2000 sp3. How many people actually have the framework? If microsoft wants people to programme with .NET then they have some work to do...

I have it, it is on windows update, and I always install it after a clean install :p

2k3 is the only OS now to come with it atm :p

Before .net was final, the framework was 34mb, so they have improved it a lot :p

Test: .net framework

[NXPdev]

It doesn't matter if it's written in "traditional" or not. Ticking that option compiles it to run on the Framework. The language it was actually written in is irrelevant. Managed code is "managed" because the CLR "manages" its execution.

--

Danny Smurf

I don't agree - if you are still doing all the memory allocation and other low-level activities yourself, then the CLR does much less and it's not really managed code.

[smurfiness]

I don't agree - if you are still doing all the memory allocation and other low-level activities yourself, then the CLR does much less and it's not really managed code.

But you're not actually doing the memory management yourself any more. When a C++ project is compiled with managed extensions, it's subject to garbage collection just like every other program running on the Framework. The new calls allocate memory from the managed heap, just like new (or equivalent) does in all .NET languages, and the delete calls do the same thing as the Dispose method... everything except the actual memory reclamation.

As for the other "low-level activities," you can do most of them yourself in any .NET language, using Interop. Just because the ability to do low-level things is there does not mean that the app is no longer managed.

--

Danny Smurf

[NXPdev]

But it isn't doing it via Interop!

[azcodemonkey]

From MSDN:

Compiling with the /clr option does not alter the semantics of an existing C++ program. For example, C++ classes do not become garbage collected or seamlessly interoperate with Visual Basic unless they are modified. Such features are only provided for Managed Extensions classes

[NXPdev]

Which, unless I am mistaken, means that Explorer isn't managed code yet!

[azcodemonkey]

Not unless they've changed its classes to __gc classes or wrapped them in __gc classes, and made other modifications. I would think it would probably be easier and a better idea just to rewrite explorer and other shell features from scratch. It would more than likely eliminate some unknown security problems with the legacy code.

Edited May 24, 2003 by weenur

[smurfiness]

Not unless they've changed its classes to __gc classes or wrapped them in __gc classes, and made other modifications. I would think it would probably be easier and a better idea just to rewrite explorer and other shell features from scratch. It would more than likely eliminate some unknown security problems with the legacy code.

*THWAPS his forehead* Of course, you're right. My bad. I forgot about switching the classes to __gc. Been spending a bit too much time in C# for the last year.

Which, unless I am mistaken, means that Explorer isn't managed code yet!

Well, we still don't know that, do we? I haven't seen the source code, and I'm willing to bet no one else outside of Microsoft has either. Maybe Microsoft has made all of the appropriate changes already, and Explorer is managed.

As for rewriting the shell from scratch... probably a good idea. Unlikely to happen. The shell isn't just explorer.exe. There are a lot of DLLs that go with the shell, which would also need to be rewritten. And since a good portion of the Windows API resides in those DLLs, changing or rewriting them breaks every app that depends on them (including any app that adds something to recent docs, any app which calls the Browse For Folder dialog, and any app that calls a SHGet function)... which is something I don't THINK Microsoft is going to do. They're including legacy graphics code for older apps in Longhorn, which means other legacy code (shell included) is probably staying as well, which probably means it's going to be impossible to completely scrap and rewrite any system-level components (shell included).

That is, unless Microsoft's got something huge up their sleeve that's going to fix the legacy problem.

--

Danny Smurf

[Glowstick]

I had explorer crashing on me in .NET classes. I would try to reproduce that and make a screen of it, but reinstalling Longhorn in VPC is a pain in the ass.