When it has come to redoing or reinstalling Delphi, I've run into a hassle. When it comes to components and units I've produced to use in projects, I run into having to go through the entire backup of my projects to find all the things I've used in other projects and copy the units over, install the components through the Delphi interface, and make sure everything is present. Then, I usually forget something and then when I pull out a project that uses one of these units or components, I have to stop whatever I'm doing, find the backup disk, find the data do the install, before I continue...
Main question: Has anyone come up with anything to solve this scenario by automating all of this? Otherwise, what do most people here do when it comes to administration of Delphi in this way?
Some tips:
when possible, avoid installation of components and create instances at run time. This will reduce the time to install them in the IDE. For example, all non-visual components do not have to be installed for design mode.
use a build tool like Apache Ant to compile projects with a build script. The build script then also serves as documentation of environment and source path requirements. When I run the build on a new computer, I only need to check the Ant build script configuration file to see which dependencies exist.
Everytime I produce my own components I consider them as a product I would sell. In this sense, what I do is to build a setup wizard that installs the components in Delphi IDE in the very same way it would for a customer.
Anytime I have to reinstall my computer or Delphi, I just have to run my setup wizards and all the work environment gets ready.
I use InnoSetup (http://www.jrsoftware.org/isinfo.php) to build my setup wizards.
I set up Environment Variables
Delphi menu \Tools\Options\Environment Variables
New User Overrides, Example: Variable Name: OutsideComponents; Variable Value: C:\mycompdir\mycomp
Lots of options in how to use the EV's
You can Set them up to use for all your projects...
Delphi Menu \Tools\Options\Delphi Options\Library path Example: $(OutsideComponents)\
Or just link use them in the project..
Delphi Menu \Project\Options\Directories/Conditionals\Search Path Example: $(OusideComponents)\Comp1
Related
We use Delphi 10 Seattle. Inside our code we use different compiler directives to produce different exe files, like debug, release version, or versions with different features sets (disable some functions for different customers ...)
Current way of getting the exe files:
change compile options by hand manually typing inside DELPHI IDE ...
compile and copy *.exe to a new location by hand
Any way to get this with one button click (faster approach ...)
Create a build configuration for each of your different feature sets.
Documentation for build configurations is here: Build Configurations Overview. This is the mechanism that the IDE provides for switching between debug and release builds, and there is no reason at all for you not to use the same mechanism to switch between your own configuration sets.
The option set feature allows you to extract certain sets or groups of options into separate files which can then be applied to configurations. You can apply the same option set multiple times, for instance once on top of a base release configuration, and then again on top of a base debug configuration. The build configuration functionality supports inheritance which makes it possible, with a bit of up-front design, to develop a clean hierarchy of configurations.
This configuration functionality is built on top of msbuild which means that you can use the same configurations in your command line builds. In fact, the fact that you mention changing configurations manually in the IDE is a concern. Building your product is not something that should require manual intervention. It is critically important that you address this and arrange that your build process is automated. You can use tools for this, although it is very easy to write your own simple tools that will invoke msbuild for all the configurations that you need to build. Please don't use the IDE to build for release.
As an aside, build configuration is one area of the product where the functionality of RAD Studio surpasses that offered by Visual Studio, in my view.
At my work we are just starting to use TFS with our team of 4 developers, and are at the same time transitioning from single developer projects to team projects. We are mostly using the default settings in TFS
I was the first to push up a simple Silverlight MVVM project consisting of a solution with a Silverlight and a web project.
When my team-mate pulled down my code and tried to compile, he was faced with many missing references (.dlls), Expression blend SDK, Ria Services toolkit, Telerik controls, simple mvvm toolkit, silverlight toolkit, etc.
What do we need to do, to add projects to TFS that have everything needed to be compile it when the next developer pulls it down?
There isn't a really good way to do this all automatically. What you'd generally do this this:
in your branch create a bin folder next to your src folder.
in the bin folder create folders for each component you're relying on
in each folder place the setup or a link to the setup
in each folder place the binary files you're using in your solution
in each folder place a readme with any manual steps that must be completed
if wanted you can create a powershell script or batch file which installs all required components. It isn't too hard to detect whether or not an application is already installed using powershell and wmi
Now you'll have to fix a few things in your solution:
make sure your references don't point to the GAC, but that they point to the assemblies inside the bin folder of your branch
make sure all the paths are relative to the solution. Any c:... paths will not carry over from one system to another
I found that the easiest way to do this is to unload the project in Visual Studio and then edit it. You can then quickly add hintpath="..\..\..\bin\component attributes to each reference. There are a few blog on this subject which provide different solutions which all solve this same issue.
This setup allows you to at least get the latest version of any solution and build it without having to install any tools. If some of your components rely on visual studio add-ins, then the designers for these tools usually won't work, but at least you're able to build them.
An often used alternative is to create a Virtual Machine base image for your project and install all the required components onto it. Then copy the image to each developers workstation and sysprep it to ensure they all have a unique name and identifiers. When the project needs to update its dependencies, let one developer create a new clean machine and re-distribute that to all team members.
If you're using Windows Server Virtualization or VMWare, it's quite easy to create differencing disks and allow developers to access these images remotely.
Another approach would be to use NuGet and script NuGet using a powershell script for your solution. This will work for most cases, but products like Expression Blend still need to be installed separately.
I like to backup up the source code set for a project when I release a version. I use GExperts project backups, which seems to gather up all the files in the project manager into the ZIP file. You can also add arbitrary files to this file set, but I'm always conscious of the fact that I haven't necessarily got all the files. Unless I specifically go though the uses clauses and add all the units I have sources for to the project, I'll never be sure of storing all the files necessary to recreate the installable/executable.
I've thought about rolling an app to traverse a project, following all the units used and looking down all the search paths and seeing if there is a source file available for that unit, and building a list of files to back up that way, but hey - maybe someone has already done the work?
You should (highly recommend) look into Version Control.
e.g. SVN (subversion), CVS
This will allow you to control revisions of all of your source. It will allow you to add or remove source files, roll back merge and all other nice things related to managing project sources.
This WILL save your a$%# one day.
You can interpret your question in two ways:
How can I make sure that I backup at least enough files so I can build the project
How can I make sure that I backup not too many files so I can still build the project
The first is to make sure you can build the system at all, the second to allow you to clean up unused files.
For both, a version control system including a separate build system is the way to go.
You then - for each new set of changes - can use these steps to assure that both conditions hold:
On your daily development system, check in the new revision of your source code into your version control system.
On your separate build system, get the latest version of your source control system.
Build the project on the build system; if this fails, go to Step 1, and add the missing files to your version control system from your development system
Start removing (one-by-one) files from the project that you suspect are not needed, then rebuild until it fails.
When the build fails, restore that particular file from the version control system, then continue step 3 with the next candidate
When the build succeed you have the minimum set of files.
Now make a difference overview of the files in your version control system, and the build machine.
Mark the files that are in your version control system but not on your build machine as deprecated or deleted.
Most version control systems have good ways of generating a difference between the files on your development or build system against the files in the version control system (usually fine grained for each historic point in time you added/removed/updated files in your version control system).
The reason you want a separate build system (or two separate development systems) is that you want them to be independent: you use one for developing, and the other for checking if the build is still OK.
This is the first step that in the future you might want to extend this into a continuous integration system (that runs unit tests, automatically creates product setups and much more).
--jeroen
I'm not sure if you're asking about version control or how to be sure you've got all the files.
One useful utility I run occasionally is a program that makes a DirList of all of the files in my dcu output folder. Changing the extensions from .dcu to .pas gives me a list of all of the source code files.
Of course it misses .inc files and other non-.pas files, but perhaps this line of thinking would be helpful to you in some way?
The value of this utility to me is that a second housekeeping utility program then makes a list of all .pas files in my source tree that do not have corresponding .dcu files. This (after a full compile of all programs) generally reveals some "junk" .pas files that are no longer in use.
For getting a list of all units compiled into an executable, you could let the compiler generate a MAP file. This file will contain entries for all the units used.
We have an automated build and QA process for our software, using tfs/teambuild and msbuild, and we want to be able to know (for audit purposes) whether a component has gone through that process or not.
For example, if a library is installed on a user's machine, I'd like to be able to inspect it in some way to tell that it went through the build. In particular, I want to be able to distinguish it from components built directly on a developer's machine, and then manually installed.
What is the best way to do this? Code signing as part of the build process seems closest to these requirements, but presumably this would not cover any 3rd-party libraries that might be used? I also read about the ILMerge tool to merge all assemblies into one, but then I don't know enough to work out whether they can then be signed or not?
I'm sure we're not the first people to have the requirement, so casting around for any ideas or hints from others who might have done such a thing
Thanks!
Our developer builds are set to keep the versions at "0.0.0.0", but our build server marks the build based on a pre-configured version and automagically generated build string. "1.0.3.xxx". Your build server doesn't allow for this?
Your build process should be updating each of your projects assemblyinfo.cs files (or a global linked equivalent), you can do this with the TFS changeset number, so like the previous poster indicated you end up with the property on each dll of 1.0.changeset.buildno or something similar. You can do this easily in msbuild.
You could have the values of each assembly info file set in source control to be something obvious like 0 or 999.
A lot of what your asking is about process and training as well though.
If your using installers or zips to package your deliverables then you can also label them with the build number as part of your build process.
But if you have changeset you have the link from dll to code, so traceable, coupled with links to third party dll references as defined in each csproj.
Does anyone have any experience of using the project config option with the Delphi Compile Action in Finalbuilder 6.
Currently the build server is set up to manually have all the correct search paths, Compiler options etc set directly on the compile action. This avoids changes to the config file breaking the build, and also search paths etc may be different to dev machines. However it can be a pain to change as it needs to be done in FB rather than in the project.
With the new BuildConfig options in Delphi2009 (and support for them in Finalbuilder 6) it
should be possible to keep this config in SCC and make it easier to maintain and update.
Has anyone tried this?
I use a virtual machine to make a stable build environment, and keep all the options in FinalBuilder. This way I know that I can make a one line change and it will be a good build, with no way I can break things by changes on my dev PC. Of course I do have to update the components etc occasionally, but that can be snapshotted and tested more carefully.
So I guess I've not tried the build config, but I don't want to!