I want to install PowerShell2.0 on a Win2k3 system. I was told to go download and install .NET Framework 2.0. Stupid me figured that .NET Framework 4.0 would work fine. (It's two better, innit?) Turns out it's not.

I'm still uninstalling 4.0 and installing 2.0 (and getting stuck with the ununinstallable "Windows Imaging Component" that 4.0 required), but what the hell is with all the .NET versions?

ISTR that 2.0 obsoleted 1.1, but it seems that if I want it all installed (and why I would want that I don't know), I have to install versions 2.0. 3.5 and 4.0.

What I'm looking for is how they're different, why I would want one as opposed to another (other than specific software prerequisites), and how they manage to be completely distinct from each other.

Update: I finally finished installing 2.0, and now I have to install SP2. It's unclear if I needed to install 2.0 first, or if it's incorporated in the SP2 installation.

I can't really explain it, but my general handling was to always install via Microsoft Update. I figure it's got at least some sense in the order that things should be installed in. SP2 is likely a newer rollup of all the previous .Net 2.0 security patches, and would have to be installed after 2.0.

I never understood it either. After glancing over the wikipedia article I still don't.
http://en.wikipedia.org/wiki/.NET_Framework
Certainly *looks* like it's explaining something, though. Maybe my brain is too dense.
At any rate, I think it's 3.5 that's the 'catch all' installation.

I can't agree with Tom more on this one. Definitely go through Windows Update for things like this, as it certainly has an order to the way it likes to do things. Didn't we have something just like this in regards to updates in another thread?

The thing that you can download from Microsoft's site seems to include 2.0 and SP2. It installed on its own after uninstalling plain-flavor 2.0. I've got more machines to run this on, so I can doublecheck.

I didn't even think about installing it through Windows Update. I forgot that there are optional packages available through there. However, I'm trying to automate some software installations, and Windows Update isn't exactly conducive to that.

Microsoft's marketing department do love to confuse matters.

.NET 2.0, 3.0 and 3.5 (and their various service packs) all use the 2.0 version of the Common Language Runtime specification (i.e. the main library that makes everything work). So code built for .NET 2.0 should work fine on all of them (unless of course you get an odd case where a bug fixed in the CLR over the period breaks something).

What 3.0 and 3.5 do is add extra functionality in extra separate libraries. It would have been a lot less confusing for everyone if the naming had made that clear

The command line version of the Web Platform Installer can be a useful way to get .NET and other dependancies installed.

So if I need 2.0, I should be able to install 3.5 instead? And probably should?

And 4.0 is (binary) incompatible?

WPI still means I'll have to redownload the Framework on every installation.

Yes.



That I'm not 100% sure of. I think that stuff built for an earlier version is supposed to work against the newer version of the CLR, except where it calls stuff that has had breaking changes. But I could be wrong, if I have stuff that was built for CLR 2.0 I make sure I have CLR 2.0 installed...

There is some stuff coming for it that lets you setup a local cache of the dependancies, like the CLR. But I don't think they've released it yet.

Agreed. I've had packages require me to install .NET 2.0, even though I already had 4.0 installed. Highly confusing.

2.0 vs 3.5 is the really weird one. 3.5 is just 2.0 with stuff added.

Like Andy, if I'm deploying a 2.0 project I make sure 2.0 is installed. All of these versions of .net can live along side each other.

Basically, I'd run whatever it is that needs to be run- either it will work or it won't. You won't get a situation of strange behavior by having the wrong version installed.

The reason for all of the versions is that MS has been constantly improving the capabilities of the .net framework, and overall they've been really good improvements. Being used to working in 4.0, I really struggle when I move back to 2.0 projects (which I've had to do recently). Yes, we get pampered with all the new stuff- but at least it's not bloat.

Do you guys using .NET commercially think about code security (IP issues) much?

I say this because, I've come across a few commercial applications (one of which costs a small fortune) which were written in .NET and I thought I'd take a look at them in more detail.

One had no obfuscation and .NET reflector lapped it up, for the most part I was looking at something which was pretty much readable source code.

The second was obfuscated and visually looking at the code didn't make much sense, but using the .NET reflector debugger I was able to poke about at its innards and gain a very good understanding of what it was doing.

Maybe the code obfuscator wasn't brilliant, but I found that it much more logical than say poking around compiled x86 code with a dissasembler or debugger.

It's been years since I shipped anything that was based on .NET (I did a couple of projects for customers in it) and I've always had this "security" flag waving in the back of my head.

Nowadays I typically write software for the end user, rather than shrink wrap software for sale generally. So it isn't really an issue for me.

I find it very useful to be able to dig into third party code when I'm having problems with it. I've also once recovered several months of work when a client lost the code I wrote for them (and unusually I hadn't kept a copy).

And I know if I need it there are some decent obfuscation tools out there (though it has been a few years since I evaluated any of them).

Most .NET obfuscation tools have a range of settings you can set, from mildly obfuscated to very obfuscated. Maybe what you were looking at was at the mild end.

Most likely!

I found it bizarre on the other piece of software that there wasn't even the token gesture of running the free obfuscator on it.

I think back to when I was implementing some code for software protection and I basically wrote a meta-assembler to generate obfuscated code from my source - each compile of the code would obviously generate a completely different set of code.

Early on with .NET obfuscation tools they could introduce subtle bugs, which is one reason why some people avoided them. The other main reason being that most .NET developers probably have no idea their "compiled" code is so readable

I work on a banking app, so obviously security is HUGE for us. We only use an obfuscator on the encryption module which contains the code used for establishing connections to the server, including encryption, client certificates, and other fun stuff.

However, looking at the app code won't tell you much because it's fairly stupid. It just displays data and allows users to send requests back to the server. There is no database access and no business logic at all client side- this was very important to me and I pushed hard for this design from the get-go. Our architecure uses separate data-only objects between the client and server as well as inn the client so that none of the logic in our entities or back end processess is ever exposed through the client.

For example, if you looked at the code you'd see all of the fields listed that the user can input for "customer", but there's no logic at all for what it means to set a customer's password, how it is validated, and how it is encrypted to be stored in the database. We also validate all calls server side, whether they are validated on the client or not (though validation logic is exposed if it's used in both places). But someone couldn't figure out how to contect to our server directly and get bad requests through.

All of this had to pass an audit by a third party, which it did with flying colors- but we definitely developed with security in mind.

Um, wow. I opened Paint.NET with the trial of .NET Reflector, and you're right. It's pretty much just straight-up source code. Fascinating.

Who says MS dosen't support open source :p

Scary huh? Now install the visual studio plugin and you can step through all that lovely code....

Andy is right, many developers don't understand just how "source readable" their binary application actually is, they seem like awfully scary developers to me.

Well honestly, in most cases it doesn't matter how readable the compiled source code is. Unless you have some ultra important trade knowledge tucked away in your code, it just doesn't matter that someone can see how you did what you did.

And if you are writing code that IS sensitive, then you better make sure you hire developers who think about this stuff. Most probably don't because most probably don't need to.

Which is not to say that I disagree about scary developers. .Net (and Java- and other fancy languages for that matter) have definitely lowered the bar to getting compiled programs working, meaning just about anyone can write something the compiles and runs. Back in the day, if you didn't know what you were doing it was hard to get something running without some skill, much less making it do anything useful. Nowadays the tools are so powerful that it doesn't take much skill to get something running that does basically what you want- the skill comes with writing code that takes into account maintenence and an appropriate level of security- and on initial writing these items aren't valued as they should be. So any old (or young, really) developer will do, and people like me who make noise about it when people are writing crappy code are ignored in the name of getting it done, then stuck with figuring out how to miantain difficult code that has security risks.

But at least I'm not bitter.

Yeah, but I guess its somewhat dependant on the sort of industry you're in. Consumer grade applications, meh, who really cares if I can see the "source" to how you format a report or some such triviality.

However, in commercial scientific/engineering software you can guarantee that there's some sort of precious IP lurking in there, the kind of stuff that you probably wouldn't want to make it easy for your competitors to see.

For example, the non-obfuscated software I mentioned running through .NET reflector generates "data", but it's the mathematical algorithms that do all the clever bits to generate this data, they're very non-trivial, I was staggered to find them sitting there staring at me.

You're definitely right about the bar being dropped, I frequent a number of embedded forums and the number of requests you get from people asking trivial programming questions makes you worried that these people are actually trying to write embedded software, if you can't grasp the basics of software development I'd suggest that embedded development *really* isn't for you.

It's warming to know that there are other developers (here!) our there that understand IP/security issues and have them in the forefront of their minds from the outset.

FWIW I've also seen proprietary embedded devices which contain lots of IP have completely unencrypted firmware updates.

I remember the old days. It was extremely easy to write code that could be vulnerable to buffer overruns, reference memory outside the program's address space and otherwise blow up the system. There will always be bad programmers and programmers will always be lazy. It's better to have languages that make it hard for the programmer to blow up the system than to rely on programmers to do the right thing all the time IMO.

Oh yeah, don't get me wrong. I don't long for the old days and I LOVE the new tools. I just see the cost we pay for the new tools and wish we could come up with a barrier to entry that forces people to learn good coding practices.