|
Well said! I hate nothing more than CDs/installers that go right up and install something without your acknowledging what you're installing.
Of course, for the apps I write, that means it would be difficult if not impossible to ever use .NET, since my team writes installers and CD front ends/browsers. 
"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
|
|
|
|
|
|
Given that our company does most of our software installation jobs ourselves, we just bung dotnetfx.exe on the CD we take to the customers site.
--
Ian Darling
|
|
|
|
|
what *version* of the .NET redistributble you need... 
"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
|
|
|
|
|
Yes! You can not install both versions and I have heard that the new version breaks applications created with the first version...
John
|
|
|
|
|
Sure you can install both 1.0 and 1.1 at the same time.
Applications run in the framework they were compiled in, and can be forced to run in another if specified in it's manifest.
|
|
|
|
|
Q.
If I already have the .NET Framework 1.0 installed, do I need version 1.1?
A.
You will need version 1.1 to run applications built using the .NET Framework 1.1. Applications built using version 1.0 will run just fine on version 1.1 of the .NET Framework Redistributable. The application vendor should inform you whether or not you need a particular version of the Redistributable to run the application.
For more technical information, see Versioning, Compatibility, and Side-by-Side Execution in the .NET Framework.
Q.
Can I run applications built using the .NET Framework 1.0 on version 1.1?
A.
Generally speaking, yes. Application vendors can build their applications in such a way, however, that they will only run against version 1.0. These situations are rare, but they can occur. If you are unsure, check with the application vendor. For more technical information, see Versioning,
I find the answers to these two questions in the FAQ for the .NET framework redisributable interesting. The first answer says that "Applications built using version 1.0 will run just fine on version 1.1 of the .NET" the second says not exactly...
John
|
|
|
|
|
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...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
