I need to build a vdproj on a jenkins machine (Windows Server 2012 R2)- which requires devenv.exe and not msbuild. I cannot install Visual Studio.
Devenv.exe is required for a MSI package.
I've used process monitor and determined I require one more file for devenv.exe to work : api-ms-win-core-heap-l2-1-0.dll
This file does not exist on any developer machine that we have, and devenv.exe/devenv.com works on the dev machines.
Where can I find this file?
Are there other ways to build a vdproj without Visual Studio?
Virtual Machine: This sounds a little hairy I am afraid. Could you use a virtual machine - with Visual Studio on it - to build the Visual Studio Installer project in question?
WiX et al: Converting to WiX or another deployment tool besides Visual Studio Installer Projects would solve the problem? Is this a very complicated installer? Using the WiX decompiler dark.exe to decompile an MSI to WiX markup can help you convert the installer to WiX format. Quite a bit of WiX knowledge will be required to do this successfully. Maybe something a consultant could do quickly? Depends on the complexity.
Windows API-set: As far as I know api-ms-win-core-heap-l2-1-0.dll is a Windows API-set, and not a real file or real dependency as such. These are new constructs in Windows. Try opening such an API-set file with Dependency Walker to see what they redirect to. Pretty mysterious these API-sets:
An API Set is a strong name for a list of Win32 APIs. The convention
for assigning a strong name to an API Set is to use what appears to be
a dll name. But the purpose of an API Set is to provide architectural
separation between the API Set's name and its associated host DLL
implementation for improved portability of your app, so you should
think of an API Set's name as just a unique character string, and not
as a dll name. For delay load, you use the name of the API Set.
API Sets rely on operating system support in the library loader to
effectively introduce a namespace redirection component into the
library binding process. Subject to various inputs, including the API
Set name and the binding (import) context, the library loader performs
a runtime redirection of the reference to a target host binary that
houses the appropriate implementation of the API Set.
The decoupling between implementation and interface contracts provided
by API Sets offers many engineering advantages, but can also
potentially reduce the number of DLLs loaded in a process.
On disk I find most of these API-Sets in %SystemRoot%\WinSxS and %SystemRoot%\System32\downlevel.
Nice article on the technical aspects of this new API-Set feature.
Complex Executable: Though devenv.exe is just an EXE file like any other, I do think there will be dependencies for Visual Studio Installer Projects beyond just dll import tables that will be very hard to set up properly, and what about future releases when all can fail without warning? (if something changes - Visual Studio has been a pretty moving target of late).
WiX Quick Start: Here are some of the best links that I have found over time for WiX:
Some WiX Quick Start Tips - chaotic, but
upvoted. Must have been helpful.
Helge Klein's real-world WiX sample - do check this out.
Rainer Stropek's WiX Samples on Github - can be very helpful.
From MSI to WiX by Alex Schevchuk - aging content, but excellent.
Related
I made a MSI-setup for my C#-project with Visual Studio 2013 and WiX Toolset 3.9.
The result is a MSI-file which works fine.
But I need also an EXE-file (should do the same, what the MSI-file does), because many users don't know, what MSI is.
I can compile this project, when the output type is "MSI". When I set the output type to "EXE", I get the error:
"The localization identifier 'ServiceDescription' has been duplicated in multiple locations. Please resolve the conflict."
This is because I have two WXL-files (one for english, one for german), and they have the same string-ids.
I don't understeand, why the compile of MSI works, but the compile of EXE don't work.
My second problem is, that I need both, MSI and EXE. So it would be nice, if I compile the project, I will get both files automated. I don't want to compile the MSI first, change the output type manually and then compile the EXE.
So what I'm doing wrong?
I don't understand the problem statement of you need an EXE because people don't know what an MSI is. MSI has been out for 16 years and is used across the world. That doesn't make sense to me.
In my experience I only use an EXE when there is a true need for one. It's simpler to stick with an MSI if that's all you need.
Possible reasons for an EXE include:
1) Need to bootstrap / chain other packages
2) Want a nicer non-MSI user interface
3) Want a UI that prompts for language selection
4) Want to cache the MSI locally
5) Want to detect previous version and pass minor upgrade command line arguments
6) Want to ask for UAC elevation up front (not best practice)
7) You want multiple instance servicing capabilities.
8) You want to have a web downloader that pulls packages on demand as needed from the internet.
9) You want to password protect / encrypt the MSI.
10) Other scenarios that might not be remembering.
In general you don't always need an EXE just to have an EXE. In fact the design and testing gets more complicated the moment you choose to have one.
If you want an EXE you first build your setup project (output: MSI) and then you build your WiX Burn based bootstrapper project (output: EXE)
I need to install a windows service using wix. Unfortunately ServiceInstall doesn't fit my needs. It doesn't allow to specify service file explicitly and needs to be placed into the same component where the service executable file is. But my components are dynamically generated by heat each time the project is build. So I can't put ServiceInstall there.
Does anyone know alternative ways to install the service?
The service is .net one so my first idea would be to run installutil from .net framework directly.
I've spoken at length of the many limitations of dynamic installation authoring. What I would do is statically author this component for the service (using ServiceInstall ) and exclude it from the dynamic generation process.
Then again, I don't use dynamic authoring period. I don't consider it a best practice.
You can transform the heat output with XSLT transform (see -t switch) the way you want. And it is still better than falling back to installutil... Take a look at the DTF documentation (DTF.chm installed with WiX, Development Guide > Managed CAs > InstallUtil) for the reasons why using installutil is not considered a good idea.
We have a software package which is about 16 years old. It's gone through just about every version of Delphi (besides .NET ones). Over the years, things have become very confusing when it comes to cross-referencing and keeping proper setup for additional packages (like third-party libraries). I was wondering if there is some standard practice when it comes to keeping large projects (and groups of projects) like this organized.
So to explain the current setup...
This is a multi-application system. Meaning, there are 12 executable projects (and a few DLL and service projects) involved. We also keep things in SourceSafe and multiple developers work on the same code on different computers. All of these projects are more-so dumped into a central folder. The "Root" folder contains THE major EXE project (along with about 20 folders, all containing units and forms) and it almost seems like an endless hierarchy of folders and files. This one project alone has half a million lines of code involved.
Then all the additional applications aren't necessarily separated properly from this major project. Each of these projects has its own folder based in the main project's root.
The two major concerns of mine are:
How to properly set up the DCU files so that they aren't mixed in with the projects? DCU's should NOT be placed in the SourceSafe (and any similar file, for that matter) or otherwise, any file compiled from the project. Visual SourceSafe makes files read-only when they're not checked out, and DCU files (and EXE files and more) cannot be written to in this case. So how to properly separate any of such file to a remote location to avoid any mixture with the source code?
How to properly set up packages and libraries? We have the following:
QuickReports 5.05
NativeJpg library V302 -
Another anonymous reporting library
Our own component package, which requires QuickReports, NativeJpg, and the other anonymous library
All 4 of those libraries are stored in completely different places of each computer, and need some centralization. The biggest pain of setting up each new developer's computer is locating these from the lead developer's computer and copying them to the same place on each other computer (and making sure the library path is correct, etc.).
We also need to keep completely separate environments for different versions of Delphi on the same computer. This means a copy of the projects on each computer, a copy of packages and libraries on each computer, a copy of the projects and packages and libraries in the SourceSafe, etc. Each computer needs to have an identical setup. We already utilize environment variables to direct our projects where to look for certain project files (and libraries).
Another new concern: XE2 introduces 64bit capabilities. We don't plan on 64bit compiling yet, but we certainly will in the future. How do I properly differentiate 32bit from 64bit in all these projects?
What I'm really asking for is a reference to a good tutorial on how to optimize such an environment and keep it organized the best. I don't expect anyone to take the time and answer all this in the question. The projects are over 15 years old, have had the hands of 200+ developers from around the world in it, and has a LOT of cross-referencing between projects. For example, one project may use a unit from another project, and vice-versa. I personally don't like this concept, but I also didn't design it to begin with. I've been given the task to get this system organized and thoroughly documented how to set up Delphi on a new computer for new developers to work on our projects. As I'm looking at our projects (as I'm not necessarily a developer of the system, but am being pulled into development), I'm seeing a lot of confusion in how the code is organized.
I am assuming that possibly Embarcadero has some guidelines and standards on setting up such an environment?
Location of DCU files
Regarding the DCUs that are the output of the compilation process, you should specify a DCU output directory in each project file. The default value for this, in the latest version of Delphi would be fine: .\$(Platform)\$(Config). This results in sub-folders of the project directory like this: Win32\DEBUG or Win64\RELEASE.
If you set-up your project files using option sets then you will be able to control this setting (and all others) from a small number of option files.
Location of 3rd party code
You should always use 3rd party library as code. If the vendor charges more to receive the library as code, pay up. Once you have done so you simply include the source code into your version control system (VCS) and treat it largely the same way as you treat your own code. I say largely because you should avoid modifying it.
Once you have all your code in the VCS then you can put the entire source code onto a new machine with a single checkout operation.
Organisation of your projects
I personally have a strong aversion to using compiler search paths. I don't use them and include every unit that is required in a project in the .dpr file.
If you do use search paths then you make it impossible to work on variant projects.So for example, suppose you have a client that has discovered a bug in the version of the software you released 2 years ago. You would like to address that bug by releasing an upgrade to the 2 year old version of the software. It is perfectly plausible that asking them to upgrade to the latest version is not viable. Perhaps they have not paid for the upgrades. Perhaps the full upgrade has breaking changes that they do not want to tackle right now. A perfect example would be all the Delphi developers still using Delphi 7.
Now, having motivated the scenario, how would you create a build environment for the 2 year old project? If you are using search paths then they will refer to today's libraries. You would be forced to change your search path, or copy the old libraries over the top of today's libraries.
That entire headache is trivially side-stepped by not using search paths and by including all your source in the VCS.
What you should be aiming for is to be able to checkout any historic version of your program and have it build immediately. You should be able to do this with full confidence that you are building identical software to what was built at the time that version was released. This also requires you to have build automation but I can't imagine you are lacking that for a project of this size.
I'll address folder organisation. This comes from a software suite which has 50+ exe's and dll's and plenty third party libraries, so I guess I know where you are coming from...
We use Perforce as a source control system, so my default workspace's root folder is called Perforce, but I also have a couple of other workspaces set up and they are in Perforce2, Perforce3, etc.
General folder setup (starting from the workspace root folder)
General
Components
Delphi
Indy
Indy9
Indy10
MadCollection
v2.5.8.0
v2.6.0.0
Plugins
Releases
Released
... a folder for each release we publish ... (and equal to a branch in Perforce)
Work
Acceptance
Sub1
Sub2
My Environment library path in the IDE is empty (not even the BDE standard paths are in there). This ensures that a project's paths declare all path's needed and that projects are not reliant upon a particular machine's IDE setup.
We have an environment var (ie MRJ) set up in our IDE's that points to "General\Components\Delphi" so in a project's options we declare the paths to our components as $(MRJ)\MadCollection\2.6.0.0.
General holds IDE plugins and components used by our projects. We keep all versions we use in source control. That way when I have to switch back to an old release to track down a problem, I can simply pull it and build it as its library paths will still point to the version of the components that this specific release needs.
The organisation of folders in a particular work branch (Acceptance or one of its subbranches) follows this pattern:
General
Includes
MainComponent1
Project1
Project2
Shared
MainComponent2
Project3
Project4
Shared
Shared
Windows
SoftwareSuite
Scripts
Tools
MainComponent1
Project1
Dcus
Project2
Dcus
MainComponent2
Tools
Tool1
Dcus
Tool2
Dcus
The General folder holds all platform independent sources/files, the Windows folder holds all Windows specific files. Each component can hold multiple projects and will have a share folder for sources shared between those projects. The shared folder directly under General holds sources shared by all projects. The Windows folder is set up in a similar manner.
Note that each project has its own dcus folder. This is configured in the project options. As the path can be entered as .dcus, we (at least I) have this set up as the default for any new project. Each project sending its dcus to a unique folder ensures two things:
it is easy to keep dcu's out of version control by simply setting up a filter in your version control software.
more importantly it ensures that compilation/build of a project never interferes with the compilation/build of another project. I can safely change settings and build knowing that I won't be bothered by dcu's lying around from a previous build from another project.
I recommend the following practices:
Keep your library path simple, and make sure everything in the library path is either a folder that ships with delphi, or a DCU binary (library) folder in your d:\Components\ folder.
Use a MODERN type of version control. I recommend Mercurial over others. Source Safe is crap, stop using it.
Back up your environment (export registry keys etc) and restore it to the other developer PCs in a standardized way. You can keep a few .reg and .cmd (batch) files around to automate setup of a new system. you can put these scripts in your component repository in your version control system.
Outside the scope that was largely discuss before, I would recommend :
Unit testing - with DUnit for example
Continuous integration. Just to be sure that all these projects can compile on another machine and that tests are ok.
So this is heavily related to project organization and VCS strategy.
For a similar setup, a company I worked for found this configuration useful:
all third party libraries (components etc.) go to a fixed location (C:\Delphi\name-version)
Delphi projects can be checked out from version control anywhere (drive C: or D: and folder name does not matter), as all projects and scripts use relative paths
all projects are sub folders of one main project folder so checking out this one will bring the Delphi projects and other relevant resources to the workstation, and a version control update is easy to do
we use a build script (written in Apache Ant) which sits in the main folder, and iterates over all folders to build the Delphi apps and run unit and integration tests against a development database server, to verify all changes work before checking in to source control
the build script can also be run automatically on a build server (Hudson CI) on every commit to see if something broke
And a note about component libraries: avoid package installation where possible, prefer creation of components at run time. If you quickly need to apply a fix to a five year old version of a project, uninstalling / installing a dozen of packages can become frustrating. At least for non-visual components, run-time creation is a huge time saver.
Checking in third party code in source control can be very helpful, for example to share fixes which are not yet available as new official releases. Best practices are covered in the Subversion documentation chapter Vendor Branches.
Plus, with Subversion you can use svn:externals to place a specific version (tag) right into a project directory structure. This can be used both with third party library and with your own source code, and makes dependency management easier and workstation setup easier.
p.s. the Ant build script defines the search paths for everything, so it is 'the reference' for all developers how to configure the IDE, where to put the third party libs and which compiler flags to use
p.p.s. your project sounds like a lot of fun - I am open for contract work :)
My team use virtualization and when we see back it was a real good move.
We use MacBook Pro laptops and VmWare Fusion, but I'm sure other packages work fine as well like VirtualBox or VirtualPC.
It is always a good feeling to know that when a new developer starts or an old installation got trouble it is just to copy a new VM image from the master image and the setup is exactly as the original. The master image is stored on a fast USB2-disk. Now when Thunderbolt and USB3 is coming it would be even faster to copy an image. And there is no real concern about performance on a modern computer as long as there is memory. 8 GB should be enough to run 2 images in parallell. Another advantage of virtualization is that it is so easy to try What if scenario. Experiment with different configuarations and versions without any risk to disturb the real working environment.
Btw I also think that SourceSafe is crap... :-)
Somé tips:
Make one groupproject file for all the apps belonging to the project, each app in its own dir under the groupproj file
You should be able to specify which file types to include into your version control system. Make sure you set Delphi to write DFM files in text format.
You could tell Delphi to output DCUs in subdirs named 'dcu' under each app (less visaul clutter).
Third party stuff often insists on installing in distinct locations, there's not much you can do about it. Make a document describing how to setup a complete working environment and keep it up-to-date
Develop in virtual machines. A new developer gets a copy of the VM.
Maintaining for different Delphi versions? Rethink that, try to go to one version. If you absolutely must have two groupprojects and directory structures for each version. [I'm assuming you're not compiling the same app with two Delphi version, that's developer hell]
Delphi XE2 will output to different 32/64 subdirectories, that should give no problems.
With the desire to be able to reproduce a given revision of a project that is utilizing 3rd party visual component packages, what goes in SVN and what's the best way to implement/structure the SVN repos?
For non-visual components, the rule seems simple to ensure no reliance on outside repos - "no svn-externals reference to any outside repo allowed". I have a shared repo that I control, which is the only 'svn-externals' reference allowed. This makes it easy to implement and share these types of runtime itemss with sourcecode in different SVN projects. Any reference this internal shared repo is by 'svn-externals' using a specific revision number.
Visual packages seem to go counter to being able to be version controlled easily as they may have to be reinstalled at each revision. How to best create a SVN project which is able to be recreated later at a specific revision number...is there a recommended solution?
Previously we didn't worry about 3rd party components as they don't change often and we never had a real good solution. I was wondering if others have figure out the best way to handle this problem as I'm doing a spring cleaning/internal reorganization and wanted to do it 'better' than before.
Technically, the RTL/VCL source should also be in the SVN repo as well (if there's a Delphi hotfix/service pack released.)
My solution will likely be to create a virtual machine with a particular release of the Delphi environment with all visual controls installed. As we add/update visual controls, or update Delphi with hotfixes/service packs then we create a new version of the virtual machine. We then store an image of this VM revision on a shelf somewhere. Is this what you do? Does the Delphi activation/licensing work well (or at all) in this scenario?
Thanks,
Darian
You can prepare "start IDE" (and possibly "build") scripts for your projects and maintain them as project evolves in repository.
Regardless of your decision about keeping components in separate repositories and using externals, or including them in a single repository with possible branching, you should also include compiled bpl files for every component build and for every branch prepared for a specific Delphi version.
You should definitely try to keep most (if not all) of paths relative, in a worst case use environment variables to point to your root project dir.
Start IDE script allows you to keep each project and Delphi version environment spearately configured on a single Windows installation.
It should include necessary registry keys for your project and Delphi:
Windows Registry Editor Version 5.00
[-${DelphiRegKey}\Disabled Packages]
[-${DelphiRegKey}\Known Packages]
[-${DelphiRegKey}\Library]
[${DelphiRegKey}\Known Packages]
"$(BDS)\\Bin\\dclstd${CompilerVersion}.bpl"="Borland Standard Components"
"$(BDS)\\Bin\\dclie${CompilerVersion}.bpl"="Internet Explorer Components"
"$(BDS)\\Bin\\dcldb${CompilerVersion}.bpl"="Borland Database Components"
(...)
"${CustomComponentPack}"="Custom Components"
[${DelphiRegKey}\Library]
"Search Path"="${YourLibrarySourceFolder1};${YourLibrarySourceFolder2}"
(...)
You can then prepare batch file:
regedit /s project.reg
%DelphiPath%\bin\bds -rProjectRegKey Project.dpr
Where ${DelphiRegKey} is HKEY_CURRENT_USER\Software\Borland(or CodeGear in newer versions)\ProjectRegKey.
Basically it is easier when you will dump your current working configuration from registry, strip it from unnecessary keys, change paths to relative and then adapt to make it work with your project.
In such configuration, switching between projects and their branches which have different sets of components (and/or possibly using different Delphi version) is a matter of checking out a repository only and running the script.
Fortunately for us, we don't have to worry about a hotfix/service pack; we're still on Delphi 5. :D
Sigh, there was a time when an entire application (settings and all) would exist within a single directory - making this a non-issue. But, the world has moved on, and we have various parts of an application scattered all over the place:
registry
Windows\System
Program Files
Sometimes even User folders in "Application Data" or "Local Settings"
You are quite right to consider the impact of hotfixes/service packs. It's not only RTL/VCL that could be affected, but the compiler itself could have been slightly changed. Note also that running on the same line of thought, even when you upgrade Delphi versions, you need to build using the correct version. Admittedly this is a little easier because you can run different Delphi versions alongside each other.
However, I'm going to advise that it's probably not worth going to too much effort. Remember, working on old versions is always more expensive than working on the current version.
Ideally you want all your dev to be be on main branch code, you want to minimise patch-work on older versions.
So strive to keep the majority of your users on the latest version as much as possible.
Admittedly this isn't always possible.
You wouldn't want to jump over to the 'new version' without some testing first in any case.
Certain agile processes do tend to make this easier.
By using a separate build machine or VM, you already have a measure of control.
TIP: I would also suggest that the build process automtically copy build output to a different machine, or at least a different hard-drive.
Once you're satisfied with the service pack, you can plan when you want to roll it to your build machine.
It is extremely important to keep record of the label at which the build configuration changed. (Just in case.)
If your build scripts are also kept in source control, this happens implicitly.
When you've rolled out the hotfix/service pack, fixes to older versions should be actively discouraged.
Of course, they probably can't be eliminated, but if it's rare enough, then even manual reconfiguration could be feasible.
Instead of a VM option to keep your old configuration, you can also consider drive-imaging.
To save on the $$$ of VMWare LabManager, look for a command-line driven VM Player.
You might have to keep 2 "live" machines/VMs, but should never need more than that.
It's okay for an automatic build script to fail because the desired configuration isn't available. This will remind you to set it up manually.
Remember, working on old versions is always more expensive than working on the current version.
Third Party Packages
We went to a little bit more effort here. One of our main motivations though was the fact that we use about 8 third party packages. So doing something to standardise this in itslef made sense. We also decided running 8 installation programs was a PITA, so we devised an easy way to manually install all required packages from source-control.
Key Considerations
The build environment doesn't need any packages installed, provided the object and/or source files are accessible.
It would help if developers could fairly easily ensure they're building with the same version of third party libraries when necessary.
However, dev environments usually must install packages into the IDE.
This can sometimes cause problems with source compatibility.
For example new properties that get written to IDE maintained files.
Which of course brings us back to the second point.
Since Third Party packages are infrequently updated, they are placed within a slightly different area of source-control.
But, NB must still be referenced via relative paths.
We created the following folder structure:
...\ThirdParty\_DesignTimePackages //The actual package files only are copied here
...\ThirdParty\_RunTimePackages //As above, for any packages "required" by those above
...\ThirdParty\Suite1
...\ThirdParty\Suite2
...\ThirdParty\Suite3
As a result of this it's quite easy to configure a new environment:
Get latest version of all ThirdParty files.
Add _DesignTimePackages and _RunTimePackages to Windows Path
Open Delphi
Select Install Components
Select all packages from _DesignTimePackages.
Done!
Edit: Darian was concerned about the possibility of errors when switching switching versions of Design Packages. However, this approach avoids those kinds of problems.
By adding _DesignTimePackages and _RunTimePackages to the Windows Path, Delphi will always find required packages in the same place.
As a result, you're less likely to encounter the 'package nightmare' of incompatible versions.
Of course, if you do something silly like rebuild some of your packages and check-in the new version, you can expect problems - no matter what approach you follow.
I usually structure my repository in SVN like this:
/trunk/app1
/trunk/comp/thirdparty1
/trunk/comp/thirdparty2
/trunk/comp/thirdparty3...
I have, right in the root folder (trunk) a project group (.groupproj, or .bpg on old delphi) that contains all my components. (allcomponents.groupproj).
Installing on a new machine, means opening that package, and installing the designtime components. That's a drag on all versions of Delphi older than 2010, but 2010 and XE have a lovely feature so you can see at a glance, which components are designtime components.
I also, sometimes, will save myself the trouble of installing those components by hand, by making a build.bat file, and a regcomponents.bat file. The regcomponents just runs regedit , and imports the keys needed to register all those components, after build.bat has built them, and everything else.
When you move up from one delphi version to another, it's sure good to have both a batch and reg file, and a group project, to help you. Especially if you have to go through and do a lot of opening of project/packages and saving them as MyComponent3.dpk instead of MyComponent2.dpk, or updating the package extension from 150 to 160, or whatever your packages do.
We have a client/server application which includes a Windows Service and a Winform client tool. I've managed to create a Wix project in Visual Studio (2010, using the wix 3.5 toolset). I'm using the "harvest" feature on the references instead of specifying every file, because there are many library projects involved.
Problems I'm trying to figure out:
How to include referenced DLLs? Some are in the GAC, some are in a relative path within the workspace. I assume I could list each file explicitly but it seems like there should be a way for Wix to autodetect them.
How to install the service while "harvest" is enabled. All the examples I've seen require adding an explicit element with KeyPath=true. However this doesn't work with the harvest=true setting.
I realize that the harvest functionality might be a convenience which is not feasible when there are more complex things going on. Should I give up on harvesting and just try to specify each file explicitly?
Most of the examples I've seen on Wix have been just snippets of xml files. Is there anywhere I can find complete real-world examples of installing services other non-trivial setup features?
Use WixEdit. http://wixedit.sourceforge.net/
It's very easy to import an entire folder using it.
Also, check out the great WiX tutorial here: http://www.tramontana.co.hu/wix/
5.4 Services Rendered
Services can be installed and started automatically.
http://wix.tramontana.co.hu/tutorial/net-and-net/services-rendered
For even more information, check out more WiX documentation here: http://wixtoolset.org/documentation/manual