I usually make a lot of application deployment and it is very timeconsuming and uncomfortable every time to overwrite the default Powerbuilder Version information. So usually I do not bother with this. But I thought there could be a solution to give this "default" information somehow to the PowerBuilder, so after the default values were filled I would only need to overwrite the exact version number. Do anybody have an idea? Thanx in advance!
Have you looked at VersionEdit from ECrane?
We actually use PowerGen from them as well for production PowerBuilder compiles and the same capability is in there.
http://ecrane.com/
A free tool is Stampver , see http://www.rgagnon.com/pbdetails/pb-0120.html for a short tutorial.
I recommend you build your application with PBORCA (my preference) or OrcaScript. Both support setting the executable properties. PBORCA can read the properties from an INI file.
We use a small Java program to get the next version number from a database and update the INI file. If you're doing any more than clicking a button to build and deploy your app, you're working too hard. We have Jenkins jobs that watch the SVN repository and build our projects automatically.
This is what one of the INI files for PBORCA looks like before the version is set
[exeproperties]
companyname=BogoSoft
productname=BogoMojo
description=BogoMojo is BogoMojo
copyright=Reserved Rights
fileversion=5.01
fileversionnum=2
;productversion=
productversionnum=0002
;manifestinfo=
[config]
targetname=bogo.pbt
exename=bogomojo.exe
iconname=images\\bogo1.ico
pbrname=bogo.pbr
The Script for PBORCA has
profile string %%WORKSPACE%%\build.ini, config, targetname
profile string %%WORKSPACE%%\build.ini, config, exename
profile string %%WORKSPACE%%\build.ini, config, iconname
profile string %%WORKSPACE%%\build.ini, config, pbrname
profile exeinfo %%WORKSPACE%%\build.ini, exeproperties
Related
Hello I have created a LWC project in VS Code but the "SFDX: Deploy Source to Org" option is missing when I Right-click the default folder under force-app/main.
I have authorized the org and set a default scratch org.
Please help.
For scratch orgs it's more "natural" to push and pull the changes, let SFDX figure out what changed on your system / what changed server-side (new field, new report? new object? good luck spelling it all out in package.xml, life is too short for it). The team behind VSCode sfdx plugin made conscious decision to hide these options.
Try with sfdx force:source:push.
If you need single file there's still source-ish deploy command (will warn you if you're overwriting something changed on server / by another dev and you can force deploy if you want).
https://developer.salesforce.com/tools/vscode/en/user-guide/development-models
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_develop_any_org.htm
The deploy-retrieve are old school metadata api commands
Recently, I was assigned the task to create a deployment package for an application which btw, I'm totally new at. So far, so good.. Now there is a requirement to extract files from a zip file which will be bundled with the setup file. So, I had to write custom actions in the 'Commit' section of the Installer class. I added the Installer class in a new project of type 'Class Library' under the same solution. I wrote the code after 'base.Commit(savedState)'.
I tried showing MessageBox at the event entry point, used Debugger.Launch(), Debugger.Break() but somehow, no matter what I do, it seems that the custom action is not willing to be hit at all and the application just installs itself. I searched a lot of sites and blogs but no help so far.
I've assigned my installer class (SampleApp.exe, in my case) to all the Custom Action's modes (Install, Commit, Rollback and Uninstall) in the Deployment project. Any help.
P.S. I'm using a Visual Studio 2010 setup project.
Thanks, in advance!
You should probably be trying a class library Dll, not an executable (which is typically for something like a service).
You don't need it all the nodes if all you're doing is calling at Commit. And why Commit? Install is just the same in most cases.
If you're not seeing a MessageBox then probably your CA isn't being called, and that may because it's not a class library. Note that your CA is not running in the interactive user context - it's being called from an msiexec process running with the system account, so you must be very explicit about (say) the path to the zip file, and any user profile folders will probably fail because the system account doesn't really have them.
What files are these and where are they going on disk? If they are user profile files you can install the zip files to a per machine location and then have the application itself unzip the files to the desired location on first launch. Unzipping from within your setup is not good practice - it is error prone and bad design.
Using the application allows proper exception handling and interactivity (the user can be informed if something goes wrong). Set some registry flags in HKCU when you have completed the unzipping so it doesn't happen more than once, and perform the unzip once per user.
I was trying out the Reflexil plugin for Reflector v7.4. Everything it promised about code change worked fine. Then I wanted to change some assembly attributes mainly the version and was successful when loading the assembly again in reflector and verifying. But when I saw the assembly in Windows Explorer it still showed the old assembly version. Please go through the images to verify the fact. What in the Thor's name is going on. Somebody please help.
Interesting one ... it has to do with managed vs. non managed worlds coliding. If you check this Stackoverflow answer out it may help you.
If you open your exe in Visual studio (Open->File then choose you .exe), you'll see the unmanaged version information. Reflexil is not changing it ... it is only changing the attribute values in the managed portion of the application.
You can see the detail if you go to scooter software and get beyond compare, compare the patched exe with the non-patched - by default it too shows the non-managed version information. You can however do a hex compare for more information -> go to Session -> Compare files using -> Hex Compare. In the middle of that compare, you'll see the managed .net version differences - but towards the end of the file past the area where the managed code and resources are, you'll see the unmanaged version information ... and it is unchanged after patching the attribute values using Reflexil.
If you have Visual Studio, you can change the versions by just opening the exe, going to the VERSION information and chaninging the values to what you want and clicking save.
I'm trying to customize the location of the user.config file. Currently it's stored with a hash and version number
%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\
I want to it be agnostic to the version of the application
%AppData%\[CompanyName]\[ProductName]\
Can this be done and how? What are the implications? Will the user lose their settings from the previous version after upgrading?
I wanted to add this quoted text as a reference for when i have this problem in the future. Supposedly you can instruct the ApplicationSettings infrastructure to copy settings from a previous version by calling Upgrade:
Properties.Settings.Value.Upgrade();
From Client Settings FAQ blog post: (archive)
Q: Why is there a version number in the user.config path? If I deploy a new version of my application, won't the user lose all the settings saved by the previous version?
A: There are couple of reasons why the
user.config path is version sensitive.
(1) To support side-by-side deployment
of different versions of an
application (you can do this with
Clickonce, for example). It is
possible for different version of the
application to have different settings
saved out.
(2) When you upgrade an
application, the settings class may
have been altered and may not be
compatible with what's saved out,
which can lead to problems.
However, we have made it easy to
upgrade settings from a previous
version of the application to the
latest. Simply call
ApplicationSettingsBase.Upgrade() and
it will retrieve settings from the
previous version that match the
current version of the class and store
them out in the current version's
user.config file. You also have the
option of overriding this behavior
either in your settings class or in
your provider implementation.
Q: Okay, but how do I know when to
call Upgrade?
A: Good question. In Clickonce, when
you install a new version of your
application, ApplicationSettingsBase
will detect it and automatically
upgrade settings for you at the point
settings are loaded. In non-Clickonce
cases, there is no automatic upgrade -
you have to call Upgrade yourself.
Here is one idea for determining when
to call Upgrade:
Have a boolean setting called
CallUpgrade and give it a default
value of true. When your app starts
up, you can do something like:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
This will ensure that Upgrade() is
called only the first time the
application runs after a new version
is deployed.
i don't believe for a second that it could actually work - there's no way Microsoft would provide this ability, but the method is there just the same.
To answer the first question, you technically can put the file wherever you want, however you will have to code it yourself, as the default place the file goes to is the first of your two examples. (link to how to do it yourself)
As for the second question, it depends on how you deploy the application. If you deploy via a .msi, then there are two hashes in the properties of the setup project (that the msi is built from), the 'upgrade code' and the 'product code'. These determine how the msi can be installed, and if it upgrades, overwrites, or installs beside any other version of the same application.
For instance, if you have two versions of your software and they have different 'upgrade' codes, then to windows they are completely different pieces of software regardless of what the name is. However if the 'upgrade' code is the same, but the 'product' code is different then when you try to install the 2nd msi it will ask you if you want to upgrade, at which time it is supposed to copy the values from the old config to a new config. If both values are the same, and the version number didn't change then the new config will be in the same location as the old config, and it won't have to do anything. MSDN Documentation
ClickOnce is a little bit different, because its based more off of the ClickOnce version # and URL path, however I have found that as long as you continue to 'Publish' to the same location the new version of the application will continue to use the existing config. (link to how ClickOnce handles updates)
I also know there is a way to manually merge configs during the install of the msi using custom install scripts, but I don't remember the exact steps to do it... (see this link for how to do it with a web.config)
The user.config file is stored at
C:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<version>
<C:\Documents and Settings> is the user data directory, either non-roaming (Local Settings above) or roaming.
<username> is the user name.
<companyname> is the CompanyNameAttribute value, if available. Otherwise, ignore this element.
<appdomainname> is the AppDomain.CurrentDomain.FriendlyName. This usually defaults to the .exe name.
<eid> is the URL, StrongName, or Path, based on the evidence available to hash.
<hash> is a SHA1 hash of evidence gathered from the CurrentDomain, in the following order of preference:
1. StrongName
2. URL:
If neither of these is available, use the .exe path.
<version> is the AssemblyInfo's AssemblyVersionAttribute setting.
Full description is here http://msdn.microsoft.com/en-us/library/ms379611.aspx
(I'd add this as a comment to #Amr's answer, but I don't have enough rep to do that yet.)
The info in the MSDN article is very clear and appears to still apply. However it fails to mention that the SHA1 hash is written out base 32 encoded, rather than the more typical base 16.
I believe the algorithm being used is implemented in ToBase32StringSuitableForDirName, which can be found here in the Microsoft Reference Source.
So, I now know what to save from nightly builds. What about when I give something to customers?
For example, I probably want to save debugging information (e.g. PDB).
What else?
We use:
installers
binaries
pdbs
tag of source files
any other source files that might not be in svn - for example config.status
build log
You made me wonder if I'm missing anything important
Compiler and library version information (it may not be part of the build log). Somebody else mentioned the whole binaries.
Linker map file (it can sometimes help the remote debugging of a problem).
Unstripped executable (if on a Unix system you strip it the executable before making it available to clients).
For the SDK releases we do include:
PDB and XML for the libraries (packaged with the latest snapshot of the samples)
Packaged snapshot of sources from SVN (just because we can)
Link to the online documentation (docs are generated from the source automatically)
Trace messages don't necessarily need to be generated by default but the possibility to enable them can be very helpful.
Results and Information generated from ATPs that are run on the build (probably as part of the build process).