|
This happens due to some code breaking changes introduced by version 1.1 of the .NET Framework.
You can teste your application thoroughly to see if it runs stable in a specific version of the CLR, but as a general rule of thumb it is best to run your application on the .NET Framework version in which it was compiled, just to play it safe. To ensure a program just runs on a specific .NET Framework version use an application configuration file
As to Side-by-Side execution, you can have several versions of the .NET Framework installed on a computer. They function independently. So you can have two programs running at the same time, one that uses .NET Framework 1.0 and another that uses .NET Framework 1.1.
|
|
|
|
|
apferreira wrote:
As to Side-by-Side execution, you can have several versions of the .NET Framework installed on a computer. They function independently. So you can have two programs running at the same time, one that uses .NET Framework 1.0 and another that uses .NET Framework 1.1.
Thanks for the info. Somewhere I read a message in a forum that stated that you could not install both at the same time.
John
|
|
|
|
|
... and target market. If most of your customers will have XP, then you can probably get away with not including it at all. Or if you distribute on a CD, you can put it there, no problem.
But if you have a 2 meg web download that you want anyone to run, you're pretty much toast. Including a 20 meg redistributable would be the equivilant of the tail wagging the dog.
Maybe in a few years, everyone will have XP and/or broadband connections... but for now, the majority of users are running something less than XP with a dial-up connection.
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
Err... WinXP don't have any .NET runtime installed as standard, so there is no difference between XP and all other Windows'...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Yes, but IIRC, XP recognises .NET applications anyway, and indicates you need the framework. Pre XP systems don't do this.
--
Ian Darling
|
|
|
|
|
Really?
Did not know that...
Anyway, I don't see how this helps when talking about the size of the runtime. 
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Anders Molin wrote:
Anyway, I don't see how this helps when talking about the size of the runtime
True enough  Shame you can't break it down into more modular bits - after all, most people won't need the ASP.NET bits for end-user applications. You could get the tools to generate a dotnetfx-dependencies.exe for your application, and it just includes the bits you use. That would probably help considerably.
--
Ian Darling
|
|
|
|
|
Ian Darling wrote:
Shame you can't break it down into more modular bits
I think that just makes distribution even harder because somebody wouldn't know what parts they already have.
Even though ASP.NET by default is only used by IIS, you can use ASP.NET from within your own winforms application by using the hosting API. There also wouldn't be much in savings by excluding ASP.NET from the redist, a meg or two at most.
You might have a case for making a server-only redist though, I can't think of how you would use the WinForms stuff from within ASP.NET (unless you generate your winforms app at runtime, but that seems a bit overboard). But again, you don't save a lot by doing so, so you might as well keep everything all together.
James
"I despise the city and much prefer being where a traffic jam means a line-up at McDonald's"
Me when telling a friend why I wouldn't want to live with him
|
|
|
|
|
Yeah, I guess you're right. I suppose I meant "Longhorn" instead of XP. 
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
Navin wrote:
Maybe in a few years, everyone will have XP and/or broadband connections... but for now, the majority of users are running something less than XP with a dial-up connection.
Too many people working on the CLR those days. The .NET run-time is to be upgraded at least once a year (2002 : .NET 1.0, .NET 1.0SP2, 2003 : .NET 1.1, 2004 : .NET 2.0, ...). With all sort of breaking changes, of course.
|
|
|
|
|
How do you make your applictions installer have the .NET redistributable also ?
Users.
Can't live with 'em, can't kill em!
|
|
|
|
|
hello adrian,
hehe, still trying to push .NET onto FCL, it will never happen
Crouching Tiger hidden dragon rules
Philip
|
|
|
|
|
It will happen, we have released or first .NET app and sent it to internal and external customers.
Got scotty to add the .NET msi to the policy, all PCs have .NET framework.
Cool eh ?
GOD ITS S#IT HERE
Users.
Can't live with 'em, can't kill em!
|
|
|
|
|
|
This is no different than before.
If you had a C++ or VB app you still had to make sure the clients had the same version of the C++ and/or VB run-times, not to mention data access, etc.
For example, a VB app that used a database would easily be 30MB+ install by the time you had the VB runtime, service packs, MDAC, etc.
Konstantine
|
|
|
|
|
Not always true.
I'm linking MFC statically with executable and have no problem with distributing.
It's better to have 800 kb .exe than have 500 kb + 300 kb of troubles.
rrrado
|
|
|
|
|
This thread also applies to your thread above:
Static linking; now what Micrsoft Should do is provide a C++ class library that would C++ programmers develop using .net but allow them to link statically using granular linking (ie. link on references to the .net classes). Just a thought but it will never happen.
I've said this all along, a lot of harden Windows programmers will never make the switch to .net, a lot of Windows programmers are switching to WTL, lets face it MFC is about to die, not soon but definitely in the long run. It's a good idea for MFC programmers to learn something new like WTL and ATL, STL or face a work shortage in the coming years.
Me, will I do still code in MFC, but I've use to WTL/ATL/STL, and .net, I learning the core .net stuff because the Winforms very easy to pick up, I want to have an avantage over the VB programmer who will just migrate to .net.
Lastly, you'll find moving to C# and Winforms really easy if you're a seasoned Windows Programmer.
My two pennies worth!
|
|
|
|
|
Being a veteran C/C++ developer, I don't feel the need for the training wheels of .Net, nor do I need them to be more productive. As far as web development goes, that's why we developed our C++ web app server. Blows away everything as far as performance goes, and let's me work with things that I am used to. So, why switch to .Net? Or another language, for that matter.
onwards and upwards...
|
|
|
|
|
.NET is a 20MB+ redist! We'll never sell this idea to our customers - at least not for a few years. At least with MFC you can statically link - and with WTL (my framework of choice) you don't have any real dependency woes.
When I am king, you will be first against the wall.
|
|
|
|
|
Robert Edward Caldecott wrote:
.NET is a 20MB+ redist! We'll never sell this idea to our customers
A lot depends on your customers and how you sell your software. If it is a CD based product then you have no problem. Internet distribution is a bit of a problem of course. I'm very surprised the .NET framework hasn't turned up in a service pack yet.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
I think MS is not allowed to do that anymore because of the anti-trust case. I may be wrong though... It may be that they are not allowed to bundle it as an IE update.
John
|
|
|
|
|
John M. Drescher wrote:
I think MS is not allowed to do that anymore because of the anti-trust case. I may be wrong though... It may be that they are not allowed to bundle it as an IE update.
Wasn't that why .NET was developed in the first place(*): To intermingle operating system and end-user application to the maximum as long as they where still allowed? Remember, back when they started with .NET there was a motion to cut MS into pieces.
(*)
Of course, the second reason was to change the quite outdated and complicated C-based WindowsAPI into a clean, OOP-style Interface. (Only that this will lead to two existing API for many years.)
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
kcs wrote:
If you had a C++ or VB app you still had to make sure the clients had the same version of the C++ and/or VB run-times, not to mention data access
As far as the C++ app goes, this is incorrect. You do not have to make sure the same version is present. Rather you build your installation to include the redist runtimes that you built with. The install should only install the runtimes, if these runtimes do not exist.
I won't comment on VB as I have always stayed away from using it.
Chris Meech
"what makes CP different is the people and sense of community, things people will only discover if they join up and join in." Christian Graus Nov 14, 2002.
"And when you need to hire a programmer to do mostly VB programming, it's not good enough to hire a VB programmer, because they will get completely stuck in tar every time the VB abstraction leaks." Joel on Software Nov 11, 2002.
|
|
|
|
|
No you don't, as other said, in C++ you can statically link everything and have a self-contained executable.
For VB, you do have to redistribute DLLs, but you don't have to instal them on the system - they can live in the same folder as your app. They aren't quite 20 meg, either, they're more like 4 or 5. But that is yet another reason NOT to use VB 6 or below.
"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein
|
|
|
|
|
Navin wrote:
For VB, you do have to redistribute DLLs, but you don't have to instal them on the system - they can live in the same folder as your app.
Yes you do not have to install them, but they are still part of the install program. Also, things like MDAC are installed where MS wants them (all over the place).
They aren't quite 20 meg, either, they're more like 4 or 5. But that is yet another reason NOT to use VB 6 or below.
As I said in my post, what I was comparing was VB and data access. Otherwise it is not an apples to apples comparison. the .NET framework has so much more than the VB runtimes so comaring the VB runtimes (or the C runtimes for that matter) is really not a valid comaprison in my mind.
Could be wrong, but AFAIK when using C++ and data access, but you would need to install MDAC also.
I guess what I am saying is if your install is 10MB already, what is another 10MB between friends
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
