Representative line: Packaging


  • Garbage Person

    conf.SelectSingleNode("/configuration/applicationSettings/Database_Application.Settings/setting[@name='DBConnString']").FirstChild.InnerText = Context.Parameters["DBConn"].ToString();

    Found in the "InstallerConfiguratorThingerMabobber" class (Yes, that's it's real name. No, I can't think of any reason why it should be named anything else) - which is called at install-time by Windows Installer to do configuration tasks - in this case rewriting the app.config file to use user-provided values instead of the dev values that are in it at compile and packaging time (Why yes, our cab files do have information on our internal configuration built right in, including server and service accounts, why do you ask?)

    Prettymuch any deployment package for Windows is going to be several levels of WTF, but this one really takes the cake. Our actual product is about 4mb. The supporting runtimes, frameworks and external application dependencies packaged with it on disk bring the total to 400mb.

    I haven't even started to unwind the licensing mess... So far I see everything from commercial software on a redist license to the GPL to Creative Commons to that silly-assed CodeProject license. Fortunately, I managed to beat into the team the importance of building a seperate module for each opensource project, so there's no license cancer problem that I have to refactor for. Our install directory looks like DLL soup, and I can't imagine how many license.txt's I'm going to need.



  • And I thought it was bad when our 4MB application (+dependencies) was bloated to 20MB by copyprotection library.



  •  Well, software today is about making the right pieces fit together in order to achieve the most in the least time. But 400MB? Damn! Are you building a new OS?



  • No, he's obviously a developer working on Adobe Reader.



  • @Weng said:

    conf.SelectSingleNode("/configuration/applicationSettings/Database_Application.Settings/setting[@name='DBConnString']").FirstChild.InnerText = Context.Parameters["DBConn"].ToString();

    That's a pretty standard location for configuration in a dot net config file.  They even went so far as to make a custom configuration section instead of just dumping everything into applicationSettings as key value pairs.

    What I find interesting is that they managed to call managed dot net code from an installer.  It's somewhat difficult and strongly frowned upon by Microsoft, even though the Visual Studio deployment tools provide a mechanism to do it.  The Visual Studio team themselves use WiX, which has no capability to call managed dot net code.

    @Weng said:

    Prettymuch any deployment package for Windows is going to be several levels of WTF
    Try WiX.  I really like it and deployment package definitions are usually just a few tens of lines of fairly readable XML.



  • @Weng said:

    conf.SelectSingleNode("/configuration/applicationSettings/Database_Application.Settings/setting[@name='DBConnString']").FirstChild.InnerText = Context.Parameters["DBConn"].ToString();

    Found in the "InstallerConfiguratorThingerMabobber" class (Yes, that's it's real name. No, I can't think of any reason why it should be named anything else) - which is called at install-time by Windows Installer to do configuration tasks - in this case rewriting the app.config file to use user-provided values instead of the dev values that are in it at compile and packaging time (Why yes, our cab files do have information on our internal configuration built right in, including server and service accounts, why do you ask?)

    Prettymuch any deployment package for Windows is going to be several levels of WTF, but this one really takes the cake. Our actual product is about 4mb. The supporting runtimes, frameworks and external application dependencies packaged with it on disk bring the total to 400mb.

    I haven't even started to unwind the licensing mess... So far I see everything from commercial software on a redist license to the GPL to Creative Commons to that silly-assed CodeProject license. Fortunately, I managed to beat into the team the importance of building a seperate module for each opensource project, so there's no license cancer problem that I have to refactor for. Our install directory looks like DLL soup, and I can't imagine how many license.txt's I'm going to need.

    One other interesting thing... Unless things have gotten better since I started using WiX, having an installer class implies using Visual Studio deployment projects, and Visual Studio deployment projects implies that builds are created by developers instead of a dedicated build script (on a controlled system).  This is a far bigger WTF than the content of the installer.


  • @Jaime said:

    One other interesting thing... Unless things have gotten better since I started using WiX, having an installer class implies using Visual Studio deployment projects, and Visual Studio deployment projects implies that builds are created by developers instead of a dedicated build script (on a controlled system).  This is a far bigger WTF than the content of the installer.

    I've never used the deployment projects, but you imply that you can't run one with devenv.com foo.sln /build "Release|AnyCPU" /project deploy_foo command from command-line (and therefore any script including continuous integration and stuff)? I use that from continuous integration to build various projects (C++ and C#), mixed together and depending on each other in one solution, so I would think it should work with installer projects too.

    Note that it also has a /deploy option, that additionally deploys the specified project, but that is for deploying CE projects to targets and Web projects to test server. I believe the installer projects are normal projects built with 'build' command.



  • @ubersoldat said:

     Well, software today is about making the right pieces fit together in order to achieve the most in the least time. But 400MB? Damn! Are you building a new OS?

     Oracle runtime can run to 500 MB so this doesn't surprise me much.  But it is poorly pakcaged if it contains server names etc. embedded into the cab files.  Windows installer properties can take care of those types of things. 



  • @Bulb said:

    @Jaime said:
    One other interesting thing... Unless things have gotten better since I started using WiX, having an installer class implies using Visual Studio deployment projects, and Visual Studio deployment projects implies that builds are created by developers instead of a dedicated build script (on a controlled system).  This is a far bigger WTF than the content of the installer.

    I've never used the deployment projects, but you imply that you can't run one with devenv.com foo.sln /build "Release|AnyCPU" /project deploy_foo command from command-line (and therefore any script including continuous integration and stuff)? I use that from continuous integration to build various projects (C++ and C#), mixed together and depending on each other in one solution, so I would think it should work with installer projects too.

    Note that it also has a /deploy option, that additionally deploys the specified project, but that is for deploying CE projects to targets and Web projects to test server. I believe the installer projects are normal projects built with 'build' command.

    Of course, this requires the $800.00 version of Visual Studio be installed on the build system, which is a lame requirement given that the .Net compilers and MSBUILD are both free.  Also, Microsoft has announced that Setup and Deployment projects will not be included in future versions of Visual Studio.


  • @Jaime said:

    Of course, this requires the $800.00 version of Visual Studio be installed on the build system, which is a lame requirement given that the .Net compilers and MSBUILD are both free.

    Ah, yes. I was always doing C++, so I needed full Visual Studio on the build server anyway.
    @Jaime said:
    Also, Microsoft has announced that Setup and Deployment projects will not be included in future versions of Visual Studio.

    @http://social.msdn.microsoft.com/Forums/en/winformssetup said:
    The InstallShield Limited Edition 2010 offers comparable functionality to the Visual Studio Installer projects. In addition, you can build your deployment projects using Team Foundation Server and MSBuild.

    It seems the replacement won't have that lame requirement.


  • Garbage Person

    @Kyanar said:

    No, he's obviously a developer working on Adobe Reader.
    No, but we DO depend on Adobe Reader... And CrystalReports 13 - which comes in two lovely redist packs that weigh in at nearly 100mb each (one x86, one x64 - and our x64 build needs both so we don't frak up some other CR-dependent app. Add in the .net 4.0 redist and suddenly your 4mb app is looking like it might need a DVD to hold it and its documentation.

     

     

     

    And yes, WIX is on the to-do list for v2.0 (or 1.5, or 1.1, or whatever the hell it's being called today) - the VS Installer projects already existed for quick hack-and-slash testing pushes (Yeah, TRWTF) so momentum kind of carried through to release. 


Log in to reply