DonationCoder.com Forum

Other Software => Announce Your Software/Service/Product => Topic started by: Josh on October 23, 2010, 03:06 PM

Title: dot Net complaints
Post by: Josh on October 23, 2010, 03:06 PM
What a shame it requires .net framework to run  :(
-PhilB66 (October 23, 2010, 11:08 AM)

And what is wrong with .NET? I have each version installed and it causes no problems on my systems. It is actually fairly decent to code in as well (I use C#, F# and VC/VB.NET). This ties right into my topic on the aversion to the .NET Framework (https://www.donationcoder.com/forum/index.php?topic=21777.0). Most complaints about .NET seem to stem from a bandwagon approach of knocking anything MS.
Title: dot Net complaints
Post by: PhilB66 on October 23, 2010, 09:12 PM
Darwin, Josh & all the other idiots that are quick to jump to conclusion... apart from stating that LangOver requires .net to run and that's a pitty because I can't test it. How on earth you decide I have something against the .net?

Oded, you should mention the requirements on your Website to save the hassle to others who don't have .net installed on their pc.
Title: dot Net complaints
Post by: Darwin on October 23, 2010, 10:40 PM
Hi Phil66 thank you for calling me an idiot. Very nice.

If you don't like mouth-breathing idiots such as myself jumping to conclusions, try being more explicit about what you mean when you post. I've been caught out this way myself in the past, but have yet to call those who jump to conclusions because of my mistakes idiots, or any other derogatory names.
Title: dot Net complaints
Post by: LangOver on October 24, 2010, 02:15 AM
Hi,

I think most of pepole have a .net installed, but I will write it in the support page.

thanks,
Oded
Title: dot Net complaints
Post by: f0dder on October 24, 2010, 04:05 PM
Easy now, all you guys :)

<offtopic>
I'm one of the people who (after I matured a bit and got over my OMFGASSEMBLY! period) have taken a liking to .NET, and find the general "it just sucks" aversion to .NET pretty silly and tiring.

There's a few relevant issues with it, though:

That's what I can think of off top of my head, and IMHO for most stuff it's not a reason to discard a .NET based language... unless you're writing stuff that needs to run on really low-end hardware or old operating systems. There's of course "portability issues", but given MONO I'd say .NET apps are somewhat more portable than native Windows apps (OK, OK, Wine).
</offtopic>

Title: dot Net complaints
Post by: PhilB66 on October 24, 2010, 07:58 PM
Darwin and all the other i..... haha, just kidding around but that's my weird sense of humor,

I sincerely apologize for being so harsh in my response. I know I could have made my point clear without being so rude. I was just a bit ticked off at that moment... sorry.  :-[
Title: dot Net complaints
Post by: Darwin on October 24, 2010, 10:14 PM
Darwin and all the other i..... haha, just kidding around but that's my weird sense of humor,

I sincerely apologize for being so harsh in my response. I know I could have made my point clear without being so rude. I was just a bit ticked off at that moment... sorry.  :-[
-PhilB66 (October 24, 2010, 07:58 PM)

Not to worry - I've been there myself  :o
Title: dot Net complaints
Post by: Josh on October 24, 2010, 10:43 PM
TICKED OFF?!?!?!?!? That's no excuse! We should have mouser submit you to torture by cody himself. Let him peck at you until your wallet is empty!
Title: dot Net complaints
Post by: wraith808 on October 25, 2010, 09:22 AM
<snip>
There's a few relevant issues with it, though:
  • .NET appsare more memory-hungry than native equivalents, and there's CPU-speed overhead as well - although it's not as easy as saying "always slower", but that's a topic on it's own.
</snip>
-f0dder (October 24, 2010, 04:05 PM)

Actually, with .NET the reason that it appears to use more memory is because of the way that memory is managed in the .NET framework, specifically with regard to GC.  The collection process requires resources. Garbage collection often derives information regarding an object’s use to make decisions on its future availability.  Garbage collection may occur at inopportune times. This can result in delays or slowdowns that may be unacceptable. Additionally, since garbage collection typically does not happen immediately upon when an object is no longer needed, the overall memory footprint of the application may be higher.  The GC in .NET also forces .NET programs to have poor locality, i.e. it interacts with local system resources in an often less-than-optimal manner, namely becasue they often consume more memory than they actually use.

Putting the long explanation behind a cut
Spoiler
The Simplified model of .NET GC
The rules:
  • All objects allocated from one contiguous range or memory (with one exception)
  • The heap is divided into generations (see diagram).
  • Objects in any generation should be roughly the same age.
  • Objects in higher generations are considered more likely to be stable.
  • The oldest objects are in the lowest addresses on the heap.
  • An allocation pointer marks the boundary between allocated and free memory.
  • Periodically, dead objects are removed and everything is “slid up” towards the lower address range on the heap.(eliminate fragmentation).
  • The order of objects on the heap is the order in which they were created (with one exception)
  • There are never any gaps between objects. (yes, another exception!)
  • Some of the free memory is committed, and when needed more memory is requested from the operating system for the reserved space.


Title: dot Net complaints
Post by: f0dder on October 25, 2010, 09:50 AM
wraith808: well, .NET apps don't just appear to use more memory than an equivalent native app, they use more memory; one reason is the structure of the .NET library and the idioms around it (there's a fair amount of objects going 'round), another is the way .NET uses it's heap. Your Win32 Private Bytes usage is going to be comparatively higher than what a native app has.

That isn't necessarily a problem, though, and it's a shame that people who think they've got a clue are quick to ramble on and on without knowing what's going on under the hood; there's a whole bunch of reasons why the way .NET manages memory is a good thing for a wide class of applications, and that the net effect is a smaller total toll on system resources... but that's too big (and way too off-topic :)) thing to write about here.

The GC in .NET also forces .NET programs to have poor locality, i.e. it interacts with local system resources in an often less-than-optimal manner, namely becasue they often consume more memory than they actually use.
-wraith808 (October 25, 2010, 09:22 AM)
Unless I misunderstand what you're writing, that's not what I understand as locality (http://en.wikipedia.org/wiki/Locality_of_reference). Yes, .NET heap can be compacted and stuff can move around, but you should generally get fine locality as long as you're using contiguous data structures... you might get temporary bumps because of compacting, but if your data lives long enough to suffer from this, it'll probably end up on the gen2 heap and not be affected much after that :)
Title: dot Net complaints
Post by: LangOver on October 25, 2010, 09:59 AM
Hi,

JAVA us better?

I think you should take things in proportional....

Oded
http://LangOver.com
Title: dot Net complaints
Post by: f0dder on October 25, 2010, 10:18 AM
JAVA us better?
-LangOver (October 25, 2010, 09:59 AM)
Nope :) (well, I don't know enough of the internals to say which environment has the upper hand head-to-head, but they use similar techniques). I'm in favor of .NET (for a lot of things), btw, if that didn't come across clearly enough :)

Could a moderator perhaps split out the whole stuff-about-.NET to a separate thread so it doesn't distract from LangOvers product announcement? - sorry for continuing the off-topicness :)
Title: dot Net complaints
Post by: wraith808 on October 25, 2010, 11:29 AM
Could a moderator perhaps split out the whole stuff-about-.NET to a separate thread so it doesn't distract from LangOvers product announcement? - sorry for continuing the off-topicness :)
-f0dder (October 25, 2010, 10:18 AM)

I'll wait until this is done to continue discussion. :Thmbsup:

Update: Though since I had to post to say that, let me just say when I say appear to use more, I mean because memory is still allocated to the application that is not actually in use; when you dispose of objects, the memory is not freed immediately.  This can't rightly be said to be used by the application since the developer is not using the objects... the memory is still just in that application's space.
Title: dot Net complaints
Post by: f0dder on October 25, 2010, 12:06 PM
Could a moderator perhaps split out the whole stuff-about-.NET to a separate thread so it doesn't distract from LangOvers product announcement? - sorry for continuing the off-topicness :)
-f0dder (October 25, 2010, 10:18 AM)

I'll wait until this is done to continue discussion. :Thmbsup:
-wraith808 (October 25, 2010, 11:29 AM)
Well, if the topic is going to be split, this reply is also going with it, so... :)

Update: Though since I had to post to say that, let me just say when I say appear to use more, I mean because memory is still allocated to the application that is not actually in use; when you dispose of objects, the memory is not freed immediately.  This can't rightly be said to be used by the application since the developer is not using the objects... the memory is still just in that application's space.
-wraith808 (October 25, 2010, 11:29 AM)
The application might not be 'using' the memory, but the thing that counts wrt. memory footprint is the Win32 Private Bytes size, not the amount of CLR memory. Keep in mind that even after GC has run, the win32 memory used by the CLR isn't necessarily reduced.
Title: Re: dot Net complaints
Post by: CWuestefeld on October 25, 2010, 12:30 PM
well, .NET apps don't just appear to use more memory than an equivalent native app, they use more memory; one reason is the structure of the .NET library and the idioms around it
-f0dder (October 25, 2010, 09:50 AM)

That's not necessarily true, although it will be in many cases. There are a couple of things that can allow for more efficient memory usage.

For example, the immutability of strings allows the reuse of a single instance of a string value, without allocating multiple redundant values.

Also, the CLR design of generics is much more efficient than any other language/platform that I'm aware of. In some cases this can allow the source code to be much smaller. Basically, the definition of MyGeneric<MyClass> only needs to be stored once; whereas C++ for example must separately compile this for each different MyClass that's used.

In general, then, some kinds of programs will take more memory, and some may take less. But that's really comparing the same program, ported to different platforms. I'm betting that if you design your code from the ground up with an understanding of .Net (or whatever platform you're building for), you should be able to come up with a design that meshes well with whatever criteria are important to you.
Title: Re: dot Net complaints
Post by: f0dder on October 25, 2010, 02:27 PM
For example, the immutability of strings allows the reuse of a single instance of a string value, without allocating multiple redundant values.
-CWuestefeld (October 25, 2010, 12:30 PM)
Possible even in C++, although that's usually implemented with COW (http://en.wikipedia.org/wiki/Copy-on-write), which can be a bottleneck in multi-threaded apps.

.NET also supports string interning, which in theory is cool, but has to be used very sparingly:
If you are trying to reduce the total amount of memory your application allocates, keep in mind that interning a string has two unwanted side effects. First, the memory allocated for interned String objects is not likely be released until the common language runtime (CLR) terminates. The reason is that the CLR's reference to the interned String object can persist after your application, or even your application domain, terminates. Second, to intern a string, you must first create the string. The memory used by the String object must still be allocated, even though the memory will eventually be garbage collected.
-http://msdn.microsoft.com/en-us/library/system.string.intern.aspx

Also, the CLR design of generics is much more efficient than any other language/platform that I'm aware of. In some cases this can allow the source code to be much smaller. Basically, the definition of MyGeneric<MyClass> only needs to be stored once; whereas C++ for example must separately compile this for each different MyClass that's used.
-CWuestefeld (October 25, 2010, 12:30 PM)
Might be true for the IL code generated, but what happens when the JIT'er runs? :) - also, there's object allocation overhead every time you use a delegate... which includes the very innocent-looking lambda expressions. Setting up the closures might be relatively inexpensive, but it isn't free (I measured a 10x speed hit in object serialization because of a INotifyPropertyChanged implementation using lambda expressions).

And as mentioned earlier, we have to keep the difference between win32 memory usage and CLR memory usage in mind. There's reasons for it; not freeing win32 memory right away means subsequent CLR allocations can be done faster. But holding on to (win32) memory until system memory pressure is high enough might leave other apps deciding against, say, allocating more cache because the available (win32) memory is low. Pros and cons.

In general, then, some kinds of programs will take more memory, and some may take less. But that's really comparing the same program, ported to different platforms. I'm betting that if you design your code from the ground up with an understanding of .Net (or whatever platform you're building for), you should be able to come up with a design that meshes well with whatever criteria are important to you.
-CWuestefeld (October 25, 2010, 12:30 PM)
Wise words. Idiomatic .NET (at least C#) programming does tend to involve a fair amount of objects being created, though. Fortunately a lot of them are short-lived and get collected fast, not putting much pressure on the win32 memory. Still, there's a fair amount of memory overhead from the framework. This becomes pretty inconsequential on larger apps that need a lot of memory for <whatever> processing, but it can be noticable on small tools. Whether this matters depends on the situation :)

The CLR memory model is really interesting when considering long-running server applications; for normal managed apps, memory fragmentation can end up being a pretty big issue, unless you're writing custom allocators. With .NET, you get address space defragmentation for free.
Title: Re: dot Net complaints
Post by: CWuestefeld on October 25, 2010, 03:14 PM
Might be true for the IL code generated, but what happens when the JIT'er runs?
-f0dder (October 25, 2010, 02:27 PM)

Hmmm, that's a good question. I never thought about it at that level. I don't know enough about how the CLR represents things at that level to know, but it may be below the level at which it makes a difference. That is, it might be that it can continue to use a just a single implementation, because at that point it's already getting a vtable as input and need not worry about the details of how it got to be so. Do you have any specific knowledge of this?

there's object allocation overhead every time you use a delegate
-f0dder (October 25, 2010, 02:27 PM)

...which shouldn't be a big deal, but in real life turns out to be a significant source of memory leakage for those who don't know it works this way. As I said, you've got to know your platform. I do this pretty extensively, and haven't had an issue with it -- but I know that I've got to clean up the delegates when I'm done, or the referenced objects won't be GC'ed.

which includes the very innocent-looking lambda expressions. Setting up the closures might be relatively inexpensive, but it isn't free
-f0dder (October 25, 2010, 02:27 PM)

Sure, but at the same time, it makes it much more straightforward to write code that operates on huge amounts of data, that stream through the app. A naive approach would involve loading all the data. Having closures makes it simple to write a program that deals with such enormous data with minimal memory footprint. This is possible in other languages (e.g., C++), but involves more difficult coding.
Title: Re: dot Net complaints
Post by: wraith808 on October 25, 2010, 04:04 PM
Update: Though since I had to post to say that, let me just say when I say appear to use more, I mean because memory is still allocated to the application that is not actually in use; when you dispose of objects, the memory is not freed immediately.  This can't rightly be said to be used by the application since the developer is not using the objects... the memory is still just in that application's space.
-wraith808 (October 25, 2010, 11:29 AM)
The application might not be 'using' the memory, but the thing that counts wrt. memory footprint is the Win32 Private Bytes size, not the amount of CLR memory. Keep in mind that even after GC has run, the win32 memory used by the CLR isn't necessarily reduced.
-f0dder (October 25, 2010, 12:06 PM)

Well, yes... but if the memory used by the CLR isn't reduced, then it is because of one of those rules stated above, correct?  So isn't that still a function of the programmer?  If you dispose of an object, and remove all pointers to it, GC should clear it up... or am I missing something?
Title: Re: dot Net complaints
Post by: f0dder on October 25, 2010, 04:14 PM
wraith808, garbage collection is done entirely at the CLR's mercy; depending on win32 memory process and which heap generation your object is in, when it's collected can vary a lot. This is just one of the reasons why you shouldn't depend on finalizers being called. Furthermore, just because a bunch of your CLR objects are being collected doesn't mean the used win32 memory is released - this makes sense because allocating system memory is "slow", so (if you're thinking only of the running .NET process and not the entire system) it makes a lot of sense to hang on to the win32 memory even if it's no longer strictly needed.

There's several different GC profiles your app can use, with different heuristics for when and how the GC works. There's also manual GC interaction you can do, but you should be really careful about this since it can seriously pessimize your app performance.
Title: Re: dot Net complaints
Post by: wraith808 on October 25, 2010, 07:47 PM
wraith808, garbage collection is done entirely at the CLR's mercy; depending on win32 memory process and which heap generation your object is in, when it's collected can vary a lot. This is just one of the reasons why you shouldn't depend on finalizers being called. Furthermore, just because a bunch of your CLR objects are being collected doesn't mean the used win32 memory is released - this makes sense because allocating system memory is "slow", so (if you're thinking only of the running .NET process and not the entire system) it makes a lot of sense to hang on to the win32 memory even if it's no longer strictly needed.

There's several different GC profiles your app can use, with different heuristics for when and how the GC works. There's also manual GC interaction you can do, but you should be really careful about this since it can seriously pessimize your app performance.
-f0dder (October 25, 2010, 04:14 PM)

Well, yes... I know it's at the CLR's discretion, but I thought that the rules pretty much covered most cases.  I also know that the generation plays a role, because it doesn't run a full GC in most cases, but I thought that memory was compacted if there were holes in between and the memory wasn't from a generation higher than what was GC'd.  Is that understanding not correct?
Title: Re: dot Net complaints
Post by: f0dder on October 26, 2010, 01:52 AM
The compacting is done to the CLR heap to remove memory fragmentation - doesn't necessarily mean the amount of win32 memory allocated for the CLR heap changes in any way.
Title: Re: dot Net complaints
Post by: kamahl on November 02, 2010, 09:14 PM
  • .NET doesn't get really interesting to program in before 3.0, which minimum OS requirement is XP-SP2. Some people are still using older OSes.
-f0dder (October 24, 2010, 04:05 PM)

That sentence is 99% correct.
However, Mono comes to the rescue.  My windows 98 box (Windows 98SE, 256MB ram) is running several programs that equire .NET 3.0+. :D

I do have my own list of issues with .NET, but they are more about the C# language specifically:

[Select]
public static void SortListView(ListView lv, int column)
{
  SortedList<int,ListViewItem> slist = new SortedList<int, ListViewItem>();
  foreach (ListViewItem i in lv.Items)
    slist.Add(int.Parse(i.SubItems[column].Text), i);
  lv.Items.Clear();
  foreach (ListViewItem i in slist.Values)
    lv.Items.Add(i);
}

That's the easiest way to sort a listview, and even then, it's assuming the column contains an int.  (The application it's used in has all but the first column as ints, and I hardcoded a check appropriate to that.  The alternative was to pad the 'int's to three figures to keep it from going out of order.
Title: Re: dot Net complaints
Post by: f0dder on November 03, 2010, 12:58 AM
That sentence is 99% correct.
However, Mono comes to the rescue.  My windows 98 box (Windows 98SE, 256MB ram) is running several programs that equire .NET 3.0+. :D
-kamahl (November 02, 2010, 09:14 PM)
Mono is a decent project, but it doesn't have WPF support - that's a big showstopper IMHO.

I do have my own list of issues with .NET, but they are more about the C# language specifically:
  • System.Windows.Forms:  Why came up with the idea that data (Listboxes specifically [They're wonderful things, all things considered]) should be kept on the control, and not in a database somewhere.  And not only that,  said data is in a read-only collection.
  • Most Collections have no .sort() method.
  • The Following code snippet
-kamahl (November 02, 2010, 09:14 PM)
The first two items on your list are .NET framework, not C#, issues :)

I don't get your item #1 - nobody (in their right mind) keeps their data in user interface controls... keep it in your model-layer objects, manage lifetime with a persistance layer, and present the objects in the GUI layer (you can use databinding, or you can shuffle values back and forth manually - your choice).

#2 - not all collections can be sorted efficiently, so it's best not adding the method where it doesn't make sense.

#3 - ugh. You're approaching things wrongly :) - exactly how to do things right depend on whole bunch of things, though. But in general, you'll want to bind your controls to objects (as opposed to string/int/whatever representations of individual properties) and use proper sorting: check out IComparable<T> and IComparer<T> interfaces. There's several ways to handle sorting, and there's more to it than just the sorting itself... for instance, it's often better practice to not sort your object data directly, but bind the GUI element to a filter/sort adapter that constructs the binding collection from it's source collection.
Title: Re: dot Net complaints
Post by: mouser on November 03, 2010, 07:51 AM
One of the real pains of distributing a dot net application seems to be worrying about and figuring out ways to deal with the situation where a required edition of the dot net clr isnt installed.

And one of the things that absolutely infuriates and confounds me is why MS did such a horrible job of helping the user to understand the problem when a dot net program runs and can't find the dot net clr runtime libraries installed.  They couldn't find a nice way to instruct the user that they need to install them?  And why didn't they write standard functions/utilities to check if the needed runtimes are installed and send user to a nice clean simple url for lay people to read about and download the proper runtimes needed.

It just boggles my mind that in designing a next generation language framework like this they couldn't have put more time into making a smoother process out of helping users figure out they need to install the runtimes and how to do it.
Title: Re: dot Net complaints
Post by: f0dder on November 03, 2010, 08:07 AM
Amen to that, mouser - the error message you get when you don't have the correct .NET framework installed is less than helpful! I don't think it would be too hard writing a little wrapper program that reads your main program assembly (or a configuration file or whatever); a quick-and-dirty test shows that Paint.NET launches even if I rename it's executable to "flafgiraf_PaintDotNet.exe.quox" :)
Title: Re: dot Net complaints
Post by: kamahl on November 03, 2010, 09:27 AM
#3 - ugh. You're approaching things wrongly :) - exactly how to do things right depend on whole bunch of things, though. But in general, you'll want to bind your controls to objects (as opposed to string/int/whatever representations of individual properties) and use proper sorting: check out IComparable<T> and IComparer<T> interfaces. There's several ways to handle sorting, and there's more to it than just the sorting itself... for instance, it's often better practice to not sort your object data directly, but bind the GUI element to a filter/sort adapter that constructs the binding collection from it's source collection.
-f0dder (November 03, 2010, 12:58 AM)

Please, offer me a better way to do it.  :D
Title: Re: dot Net complaints
Post by: kyrathaba on November 07, 2010, 05:42 PM
I have the same frustration with .NET.  I did finally manage to tweak an InnoSetup script enough to get it to detect if .NET 4.0 is present and, if not, download it.  I'm attaching a link to a downloadable zipped archive of my InnoSetupPortable folder.  It contains a directory structure housing "Character Creator.exe" (could be any other executable, just happens to be the one my script references) in the /source/ subdirectory, and a related *.iss script file in the root of the directory.  If anyone can use this as a starting-point, and develop a better script (maybe one that also prompts for installation of a desktop icon, etc.), feel free to build upon this:

http://kyrathaba.dcmembers.com/testbed/InnoSetupPE.zip (http://kyrathaba.dcmembers.com/testbed/InnoSetupPE.zip)
Title: Re: dot Net complaints
Post by: mouser on November 07, 2010, 05:50 PM
Thanks for sharing that kyrathaba  :up:

Here's how i prompt for desktop icon with Inno.

First add an ICON line:
[Icons]
Name: {userdesktop}\Name of your application; Filename: {app}\YourApplicationProgramFile.exe; Tasks: desktopicon

Then add a TASKS line:

[Tasks]
Name: desktopicon; Description: {cm:CreateDesktopIcon}; GroupDescription: {cm:AdditionalIcons}


Title: Re: dot Net complaints
Post by: Renegade on November 07, 2010, 08:57 PM
One of the real pains of distributing a dot net application seems to be worrying about and figuring out ways to deal with the situation where a required edition of the dot net clr isnt installed.
-mouser (November 03, 2010, 07:51 AM)

I don't know what you mean exactly. If you start from an installer, the installer will direct you to the proper download page. There's an exception message that tells the user that they need it, then they can opt to install it and are properly directed to the MS .NET install page. This has been around since .NET 2.0. It's much better in later versions though. .NET 1.0 and 1.1 were totally sucky for this though.
Title: Re: dot Net complaints
Post by: kyrathaba on November 08, 2010, 09:03 AM
Thanks for the info, Mouser.

I did find Byte Essence Install Maker (http://www.bytessence.com/bim.html), which purports to check the .NET Framework version (and presumably would offer to download a missing Framework).  I haven't tested it yet; but if it does what it claims, it's just what I'm looking for:  a freeware installer, no scripting learning curve, that would work well with my .NET apps.

[ You are not allowed to view attachments ]

And here's (http://mseitsetupbootstrap.codeplex.com/) something that may interest you, Mouser.  An MSI bootstrapper that detects if .NET Framework is needed prior to program installation.  It says it's licensed under the GPL.

Also, the free version of AdvancedInstaller (http://www.advancedinstaller.com/download.html) purports to check for and automate the installation of missing .NET Framework:

[ You are not allowed to view attachments ]
Title: Re: dot Net complaints
Post by: kyrathaba on November 09, 2010, 06:59 PM
Came across this DreamShield (http://dreamshield.codeplex.com/) installer, mouser, which is interesting:

DreamShield is a publishing tool through which it is possible to create installers to publish Microsoft .NET based applications. You can also choose whether to include the setup of the .NET Framework itself with your package for an easy distribution. It is possible to create setup then put them on a CD or to create a self-extracting archive with only one application in order to allow an easy downloading from a website.

It's free for both personal and commercial use.
Allows an installation to be FTPed to your website for download by end-users

Developers and documentation appear to be French, though (although the documentation can be viewed in English via a Google Translation on their website.
Title: Re: dot Net complaints
Post by: kyrathaba on November 09, 2010, 07:22 PM
SSE Setup (http://www.sharewareconnection.com/sse-setup.htm) states that it supports .NET Framework download and installation, wherever necessary.  I'm downloading it for later.
Title: Re: dot Net complaints
Post by: Eóin on January 17, 2011, 07:45 AM
The WiX - Windows Installer Xml Toolkit (http://wix.sourceforge.net/index.html) can also handle installing the .Net frameworks (http://wix.sourceforge.net/manual-wix3/install_dotnet.htm) on demand.

Personally I love WiX for installers.
Title: Re: dot Net complaints
Post by: Ath on January 17, 2011, 12:23 PM
I helped worstje getting his Inno Setup installer for JottiQ into place, for that I grabbed an existing feature from the internet, and expanded that to support .NET 4.0. It's also posted back (http://tonaday.blogspot.com/2011/01/inno-setup-preparetoinstall-scripts.html) on the internet, ofcourse. Everybody was quite happy, including me 8)