In InstallShield, why are there two productcode settings? One is in general information and another in releases > productconfig. The latter seems to be the one that matters for major upgrades. Likewise there are duplicate Upgrade Code and Package Code fields.
Product Configurations are a way of building variations of an installer from a single source project. Through the use of release flags you can create different MSI's with different feature sets and then you can override the ProductName, ProductVersion, ProductCode and UpgradeCode to give the resultant MSIs different meta context.
An example would be a Lite, Standard and Professional version of your product.
Related
Is it possible to create two work items in different project but related each other ?
Description;
i mean Project 1 has a work item "ABC", and Project 2 has work item "ABC"
if I change state of my work item "ABC" from doing to done at Project 1, is it possible to have my work item "ABC" at Project 2 automatically change from doing to done as well?
looking for help
Thank you
Regards
Azh
If you only want to relate two work items and regardless of automatically change state, you can certainly relate two work items that are in different project. What you need to do is the same as relating two work items in the same project. You can refer to this document for detailed steps.
As of this time, however, the function of automatically change work items' state is not supported. But Microsoft have added the feature to their roadmap and offered an alternative solution. Please click this link for details and documentation.
There is a vote on this function in Developer Community, where you can follow the latest development of this feature.
How can i localize the drop down option for the search mode? I did some digging and was able to adjust the localization for the search form labels but i'm at loss here.
The CMS Module SearchDialog.ascx call the drop down list here, but i can't see where the values come from.
<cms:CMSDropDownList runat="server" ID="drpSearchMode" CssClass="DropDownField" />
Go to the localization App and create resource strings for
"srch.dialog.AllWords"
"srch.dialog.AnyWord"
"srch.dialog.anywordorsynonyms"
"srch.dialog.ExactPhrase"
Believe those are the 4 you need.
I couldn't find official documentation that helps much with this, though there have been articles in the past on older versions. However, one trick I've used previously is to look in the ~/CMSResources/cms.resx file, find the localized string there, and add a new one with the same key to the Localization module in Kentico. That is, add a new resource string in Kentico with the same key (the naming will be different depending on your version of Kentico).
Here's the docs discussing setting up a multilingual interface: https://docs.kentico.com/display/K9/Setting+up+a+multilingual+user+interface
And here's a screenshot of the resx file:
So in your case I'd create a new resource string within Kentico called "srch.dialog.allwords" as an example and that should overwrite and take priority over whatever is in the .resx file, plus you can manage it via the Kentico admin. There may be a quicker or more reliable way to view the list of default resource strings but in my recent installs of Kentico, the list is hidden from the admin interface.
Alternatively, of course, you could manage the resource strings via various .resx files as in the documentation, but I try to manage as much of these pieces via Kentico as possible for convenience.
The company I am working for at the moment codify the schema or contract version into the root node. For example,
<PurchaseOrder_v1_2 xmlns="http://someNamespace">
...
</PurchaseOrder>
I am looking for people's opinions on this design approach, as I am not convinced it is sound. For example, it requires that all services using this schema as a messaging contract are able to publish multiple versions to satisfy client requirements for different versions.
I would probably disagree with #hacktick's suggestion that versioning the namespace is conventional. I've never seen the W3C recommend that the namespace changes with version - certainly W3C namespaces don't do this - both versions of XSLT have the namespace http://www.w3.org/1999/XSL/Transform, for example.
Both encoding the version into the root and the namespace are changing the name of the element. In the case of the root, you are effectively stating that is an entirely different element with no defined relationship to the PurchaseOrder element in the previous version. In the case of the namespace change you are stating the same thing about *all the elements in the language.
Version attributes are more normal. May I suggest you read this thread on the XML-dev mailing list for some very well-informed discussion?
normally you versionize the url for the schema.
so you would have a schema called "schema" and you would then make reference to this like:
"http://www.example.com/2011/01/schema" where 2011 and 01 are versions in the form of year and month.
Example:
<PurchaseOrder xmlns="http://www.example.com/2011/01/schema">
</PurchaseOrder>
another approach is to use specify the version in the root element.
if your root-element for example is called "PurchaseOrder" you would add an required version attribute (""). your version attribute would contain a simple number that increments with each version of your xsd. you must save a history of all your public xsds. this could lead to easier xsd urls but the extraction and the validation of these xml-files is a little bit harder.
Example:
<PurchaseOrder version="1" xmlns="http://www.example.com/schema">
</PurchaseOrder>
If you versionize the root element name ("PurchaseOrder_v1_2") you would have conversion problems in your xml-files if you go for another version.
Personally i would go for solution 1 (versionized namespaces). this is also recommended from the w3c. can't find a link for this statement though.
I have BasicMsi project in InstallShield. I want to be able to update this application however I cannot find InstallShield variable that returns the number of already installed ProductVersion, I know that I can workout this version manually by using Upgrade node and defining set of rules however right now I'm searching for the simplest solution. I want to use this version number in code in order to feed some tool that bases on this value.
I want to be able to upgrade to the current version, not only from the previous version (for example 3.0.2) but also from earlier ones (2.1.0, 1.0.0 etc).
If we are talking Major Upgrades your ActionProperty defined in the Upgrade table will have the ProductCode after FindRelatedProducts has executed. There is also UPGRADINGPRODUCTCODE that is set by RemoveExistingProducts.
I know of no other built-in mechanism to resolve the ProductVersion of the product being upgraded. You will have to write a custom action to query the MSI API based on your ProductCode / UpgradeCode to get this information.
An alternative would be to write a registry value during the first install ( or perhaps even use what's already stored in Add/Remove Programs Uninstall key ) and then use an AppSearch/Reglocator combo to fetch it into a property.
I've developed a SharePoint 2007 custom list with a single custom content type derived from Item. The problem is that I only get major versions when enabling versioning on the list. Is it possible to get minor version on a custom list? If not, does anyone know of a post explaining a good approach around how this might be accomplished for a custom list.
Minor versions are only available for lists based on SPDocumentLibrary - that is to say, the SPListItems must have an associated SPFile. I think you're out of luck on this unless you decide to implement the minor version as a custom column and maintain it using a custom ItemEventReceiver. Yuck.