[wix-users] Separate Component for each SqlScript element?

Edwin Castro egcastr at gmail.com
Tue May 15 10:16:23 PDT 2018


I really like the idea of custom resource provider. The ability to use any
resource as a keypath is very enticing!

I checked your links and read the "What happens if the component rules are
broken?" topic:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa372795(v=vs.85).aspx

It says:

<quote>
An author adds resources to a component without the changing the component
code.

* Products installed with the old component have no information about the
added resources in their installation database.
* If both a new product that has the added resources and an old product are
installed on the same computer, the resources can be left behind if the new
product is uninstalled first.
* An old product without the added resources cannot repair the newer
version of the component. Reinstalling the old product does not restore the
added resources.
</quote>

There is similar verbage for removing resources without changing the
component code and other scenarios.

I expect the reason the new resource was not installed is because the
resource was added to a component that was changed without changing the
component code (a component rule violation). If the keypath for that
component was a versioned file and that file was updated in the patch (it's
version is newer), then the component would get selected to be reinstalled
in the patch and the new resource would be installed as a consequence. If
the keypath of the component is not selected for any reason, then the
component is not reinstalled and the new resource is never installed.
Putting the new resource in its own component allows the new resource to be
installed because the new component never existed.

Generally, it is always best to pair up non-versioned resources with a
versioned resource as keypath in a component so that those non-versioned
resources are installed, reinstalled, and uninstalled whenever the
versioned resource is. Of course, if you a non-versioned resource that you
want to update even when the keypath hasn't changed, then you'll need some
other mechanism to ensure the non-versioned resource can be updated.
SqlString and SqlScript are paired with a component and will be installed,
reinstalled, uninstalled when that component is installed, reinstalled, and
uninstalled so the question really is, as Christopher said, why did the
keypath for that component not get reinstalled?

--
Edwin G. Castro



On Tue, May 15, 2018 at 7:54 AM, Christopher Painter <chrpai at iswix.com>
wrote:

> AFAIK, the MSI SDK only has two topics on this:
>
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/
> aa372830(v=vs.85).aspx
>
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/
> aa370561(v=vs.85).aspx
>
>
> It's not much.  I've always felt that when people shout component rule
> violation they are taking a broader view obtained from various lessons
> learned / shared.
>
>
> As an aside, I always thought that MSI should have a concept of a custom
> resource provider.
>
>
> MSI can check for things like files, registry, COM.   It's also common
> practice to make data driven custom actions that are related to component
> installation state.  I always wished it was possible to do things like
> populate a table with a custom provider ( say IIS website ) and then tell
> the component that the website is the key path.   So MSI would do it's
> resiliency health check, look up the custom provider and then use the code
> to validate if the website is valid or not.
>
>
> Also built in property persistence would have helped here a lot.
>
>
> ------------------------------
> *From:* Edwin Castro <egcastr at gmail.com>
> *Sent:* Tuesday, May 15, 2018 9:32 AM
> *To:* Christopher Painter
> *Cc:* Ven H; WiX Toolset Users Mailing List
>
> *Subject:* Re: [wix-users] Separate Component for each SqlScript element?
>
> I was under the impression the outcome of violating the component rules
> was that your keypath may not have changed so it doesn't get reinstalled
> and thus your new resource doesn't get installed. Perhaps I'm
> misunderstanding the purpose for the component rules to begin with...
>
> --
> Edwin G. Castro
>
>
> On Tue, May 15, 2018, 05:32 Christopher Painter <chrpai at iswix.com> wrote:
>
> Is that really a component rule violation or merely an issue with the
> component not reinstalling during the patch?   The SqlScript element
> doesn't have any file elements so I'm not sure the component rules apply
> here.    I'd wonder what the keypath of the component is.
>
>
> Then again I'd also consider making this an application problem.  Most
> data access frameworks have some mechanism for doing code first database
> migrations at runtime.  It sure would make the installer simpler.
>
>
> ------------------------------
> *From:* wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of
> Edwin Castro via wix-users <wix-users at lists.wixtoolset.org>
> *Sent:* Monday, May 14, 2018 11:16 AM
> *To:* Ven H
> *Cc:* Edwin Castro; WiX Toolset Users Mailing List
> *Subject:* Re: [wix-users] Separate Component for each SqlScript element?
>
> Every *new* SqlScript element needs to be under it's own *new* component.
> The component rules say you cannot add a *new* File element under an
> *existing* component. SqlScript is just another resource like File,
> RegistryValue, Shortcut, and others.
>
> --
> Edwin G. Castro
>
>
> On Mon, May 14, 2018 at 7:39 AM, Ven H <venh.123 at gmail.com> wrote:
>
> > Thank you very much for the details. So, if I understand correctly, I
> > should include every SqlScript element under it's own component as per
> the
> > Component Rules.
> >
> > Regards,
> > Venkatesh
> >
> > On Mon, May 14, 2018 at 7:43 PM, Edwin Castro <egcastr at gmail.com> wrote:
> >
> >> You are not allowed to change components. You are breaking the component
> >> rules. Rob has a few blog posts on the component rules that you should
> read
> >> and understand. I can't look them up right now, I'm on my phone, but
> I'll
> >> look for them after I get to work.
> >>
> >> The only time you can change a component is if you are doing a major
> >> upgrade *and* RemoveExistingProducts is scheduled early (so that all old
> >> components are completely uninstalled before the new, different
> components
> >> can be installed). For all other kinds of upgrades, including major
> ugrades
> >> scheduled late, you cannot change components as the Windows Installer
> >> engine requires components to be immutable.
> >>
> >> --
> >> Edwin G. Castro
> >>
> >>
> >>
> >> On Mon, May 14, 2018, 04:43 Ven H via wix-users <
> >> wix-users at lists.wixtoolset.org> wrote:
> >>
> >>> Sorry to bring this topic again. But, if we don't allocate individual
> >>> component for each SqlScript, then Patch doesn't seem to be working
> >>> properly. For example, if I have an SqlScript in first version and I
> add
> >>> another SqlScript element in my Patch, if they are within the same
> >>> component, it doesn't seem to be working. But if they are within their
> >>> own
> >>> components, then it seems to be working. Please advise.
> >>>
> >>> Regards,
> >>> Venkatesh
> >>>
> >>> On Wed, Feb 28, 2018 at 5:37 PM, Nir Bar via wix-users <
> >>> wix-users at lists.wixtoolset.org> wrote:
> >>>
> >>> > Since SqlComponent are not key paths anyway, you can nest some under
> a
> >>> > single component
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Nir Bar, Independent WiX Expert. Creator of-
> >>> > JetBA: WiX WPF Bootstrapper User Interface Framework
> >>> >
> >>> > JetBA++: WiX Native Bootstrapper User Interface Framework
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > ____________________________________________________________________
> >>> > WiX Toolset Users Mailing List provided by FireGiant
> >>> > http://www.firegiant.com/
> WiX Support | WiX Experts and Resources from FireGiant
> <http://www.firegiant.com/>
> www.firegiant.com
> WiX Support | Installation, Development, Deployment | WiX Experts and
> Resources from FireGiant
>
>
> >>> >
> >>>
> >>> ____________________________________________________________________
> >>> WiX Toolset Users Mailing List provided by FireGiant
> >>> http://www.firegiant.com/
> >>>
> >>
> >
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
>


More information about the wix-users mailing list