Heavy Plant Crossing (Light Plants Have to use the Bridge Down the Way.)
Google Search It
While vacationing in England we came across several interesting signs but this was undoubtedly my favorite. Don't the English just have a way with words?
Visual Studio Installer Complaints and Feature Requests
Google Search It
Below is a list of feature requests for the Visual Studio Installer Tool. Frankly, this took currently deserves an F. The list below was contributed to by our Alameda office and the Itron Framework team. (How about Microsoft eating some of their own dogfood with this tool?)
Ability to add not only files, but also folders and subdirectories also to the file system. (i.e) If we pass the folder it should package all the files dynamically. (Currently much of our help documentation includes generated files and adding these all manually rather than adding all the files in a particular directory (perhaps with a mask) is an absolute pain. We need the ability to "include all files in subdirectories {x} with filename filter mask {y}".
Facility to install at many networks machines/servers at a time. One click installation at many target machines at a time. Remote deploy to multiple machines.
Facility to add custom dialogs to 'Add Dialog' dialog list view and ability to include custom dialogs in between the existing UI sequence.
A means for customizing the existing VS.NET install wizard.
Ability to add custom actions before copying (installing) the files to the target m/c. It is not possible now. (i.e. Facility to add custom actions before the splash screen starts to initialize our installer or target m/c to a particular state - before actually installing anything into the target m/c)
Facility to add custom actions before/after execution of each dialog Integrate a new Design UI for Windows Installer where, we could attach events for tasks carried out before, after and during Install, Uninstall, Rollback and Commit
Ability to register the components to registry automatically like a "COM DLLs" folder in the file system with properties to auto-register the components.
Ability to install other applications (other .msi files) before/after/during the installation.
Creating shortcuts for an .exe at Desktop/Programs Files folder is not working properly.
A UI to access the MSI database and tables.
Ability to do selective installation (to add our own component tree where the user would be able to select the components that they want). Preferably this should be hierarchical like in Microsoft Office and Visual Studio.NET.
A pie chart representation for the disc cost.
In the existing UI dialog boxes, provide facility to control the size, location and other properties of the controls…, like ability to put the bitmaps vertically or horizontally or wherever we want. We need to be able to customize the UI screens.
Ability to create our own dialogs using windows forms. Perhaps requiring a deriving from an existing install dialog form.
Ability to specify parameters (such as defaults) on the command line of the install that are then passed to dialogs within the install.
Silent install support (this would require the ability to default any options on the install).
Localization: Ability to change UI culture at runtime. One installer should be enough instead of having to build different installers for different languages. Like, choosing the language of install at the beginning of installation
Package multi-tired applications in multiple installers. Ability to be able to split install into multiple machines like database server, business server etc at the same time. (for example: an UI which captures multiple install locations to install portions of a single installation).
Dialogs for creating or using existing databases, schema and tables. Running DML commands (such as a TSQL script). This should be transacted.
Unattended Installation/Silent install support.
Ability to pass command line parameters to install or sub components of the install.
Facility to show the files being copied to the user when Progress dialog is being shown
'Register User' is not working properly, throws an exception when we pass executable for custom actions.
Current VDPROJ files offer no control over whether DLL dependencies should be included or not. We have a "Core" library of DLLs that are placed in the GAC, and then multiple modules for each subsystem. Maintaining these to keep core DLLs from showing up in subsystem directories is a continual burden.
Current VDProj file is proprietary format, not XML, and there is not any public API for modifying the files.
Our GAC merge module (~90 DLLs) causes VS.NET to crash without any trace when we try to build a setup project that contains only this module.
Documentation for merge modules could be improved, especially documentation for "Custom tasks" written in C# installer classes.
Forced double-deployment of core DLLs
We are forced to deploy some DLLs in both a web/bin directory and in the GAC, since some inclusion references made from ASPX files sometimes require the presence of a core DLL in the web/bin directory.
Our installer classes sometimes rely on our core product DLLs to get their work done. But the GAC is not available at the time they run, so we are forced to deploy these dependent DLLs into the application directory as well as the GAC.
Integration into the VS.NET IDE is sometimes awkward - you could close the IDE and changes would not always be saved. VDPROJ files take far too long to load into the VS.NET IDE. They should load immediately, and do their dependency-checking work at build time.
Need to make VDPROJ projects better at detecting to support incremental re-builds. At present, even if I change no files at all, a full re-build occurs.
In building merge modules, need to detach the need of WEB projects to be referenced by the local WEB URL. This has proved painful in our build environment, where we have to build several code lines of the product.
There's no way to set the default of "install for me only/for everyone" without resorting to editing MSIs with ORCA, or use InstallShield.
There's no way to set the version string at build time, without using a tool like PERL to update the version string in a VDPROJ file before a build.
The UI editor is limited and awkward.
Integration with source control still is less than ideal. Sometimes I can overwrite a checked-in file without a prompt, other times I am warned to check a file out first (instead of this causing an automatic check-out, as happens with most other files)
VDPROJ references tend to be saved internally as absolute paths, so a module created on one machine won't work on another -> forces use to use subst to normalize drives. (This may be fixed in 2003?)
Performing textual DIFFs for different versions of VDPROJ files is practically impossible because the order of items in the file shifts every time you re-save it. This makes it difficult to see whether a file you are checking in has problems or not. As mentioned already these files should be XML.
Need a more reliable way to update DLLs that are deployed in the GAC with the same AssemblyVersion. The version-numbering scheme does not work well for strongly-typed DLLs, since you cannot bind to an updated DLL without having to modify the app.config file to make it compatible. This is too onerous in a system with > 10 distinct applications.
Need to include GACUTIL with the .NET framework distribution. In 1.1, we now have to use a DOS command prompt to copy DLLs that have the same AssemblyVersion into the GAC, since the drag and drop does not always work to do this. This is a common task for manually applying hotfixes. Hotfix support: We currently need to use InstallShield for issuing Windows Installer-integrated hotfixes. It would be nice if this was built into VS.NET.
The code build system is less than ideal. We build about 30 MSM and MSI files, and build system integration is pretty bad. We use a batch file to call DEVENV To build these in series. In future, we'd like to see stronger support for command-line, automated build tools for all VS.NET projects. We build a large number of projects into our product now, and the partitioned solution approach advocated in MSDN is not sufficient for our needs. Build tools that look like NANT and NMAKE get us part of the way there, but a build system that could operate directly on the VS.NET project file types would be optimal. The ability of a solution to control the build order is helpful, but maintenance becomes impossible when using many projects.
Perhaps many of the above features are somewhat possible via workarounds with the current product. In that case I would love to know the best practices for dealing with these issues and I request that you make it easier in the future. At a minimum documentation on how to do any of the above tasks would be great.
A New Uninvited Addition to the Michaelis Household
Google Search It
Today over breakfast our neighbor asked us if we new we had a wasp nest in the garden.
"Wasp nest? No, of course not, do we really? Hey, check that out...."
Just before spraying I discovered that both the remaining wasp spray cans in the house were virtually empty. Nothing like adding a bit of excitement. Well the spray made pretty good work of it. I sprayed after dark as supposedly the wasps are less active then (though they sure didn't seem to lack any energy based on the buzzing sound coming from the nest once I started spraying.) I was disappointed that the spray dissolved the nest somewhat as I was hoping to save it and show Benjamin. Oh well... perhaps another time.
I currently have two projects (eBible and Template Code Generator) in the works and I have not yet posted code for either of these because I am not sure what license agreement to use.
Currently I have assigned the GNU Lesser General Public License to the Template Code Generator but I believe I can change it (especially since there is not actually any source code there yet.) In spite of the fact that this license appears to be written in English I am having trouble understanding the full implications of the license.
If I reference/link to the binary created within the Template Code Generator in order to create some other assembly/package can I distribute that second assembly/package under whatever terms I choose as long as I include the Template Code Generator source code and it's accompanying license agreement of the as part of the distributable for my the second assembly/package? In other words, if I don't wish to distribute the source code or binaries from the second assembly packet under the same terms (free binaries or source code) would that be allowed?
Also, does the following quote from section 6 require me to re-distribute the .NET framework or VS.NET because I used these "utilities" to compile the binary? 'For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it.' I presume the term "executable" in the above sentence includes DLLs?
If there is a snippet of code within the Template Code Generator that I share with other software that is not distributed as open source is that allowed?
Assuming there is some part of the LGPL license that is not acceptable how would I go about modifying and still having it be acceptable to the OSI. More importantly, would this be a long an involved process or relatively simple.
Based on the complexities of this license (IMHO) I am tempted to simply post the code on GotDotNet where I can create any license agreement I like. (This of course is an advantage over SourceForge that I hadn't really considered in my original criticism of Microsoft creating workspaces on GotDotNet and it would not be surprising if this was the only reason Microsoft created the workspaces.)
