Re: [dotNetRDF-Develop] Toolkit installer

[Rob V. <rv...@do...>]

Kal

So I finally had time to look at this some more, hard coding the SDK path
has worked around the problem and I can successfully install and uninstall
the toolkit.

One problem I notice is that I don't get quite the right layout on disk, for
example the rdfEditor folder includes all the .xshd files but doesn't put
them under the expected Syntax sub-directory which means the features
related to these won't work correctly.  Similarily the StoreManager folder
does not have an appropriate Plugins sub-directory.

I am happy to work on fixing these myself but not being familiar with WiX I
can't understand how what is included is even getting decided?  It appears
to relate to CoreFiles.wxs which appears to get automatically generated
using the WiX heat tool so I don't understand how to change things.  Any
pointers here would be welcome

Thanks,

Rob

From:  Kal Ahmed <ka...@ne...>
Date:  Wednesday, 18 December 2013 22:11
To:  Rob Vesse <rv...@do...>
Subject:  Re: Toolkit installer

> Hi Rob,
> 
> It sounds like the GetFrameworkSdkPath task in the AfterBuild target is
> getting the wrong thing (you could probably insert a message in there to see
> if that is the case). However, I have no idea *why* that is happening unless
> perhaps the msbuild process / nant process is running under an older version
> of the .NET framework and is picking the wrong thing up there ? Maybe for some
> reason it thinks it is running in a 32-bit environment ?
> 
> Sorry I can't shed more light on it. I vaguely remember having a problem like
> this before but never getting to the bottom of it, I think I ended up
> hardcoding the path instead of using the GetFrameworkSdkPath task.
> 
> Cheers
> 
> Kal
> 
> 
> 
> 
> On Tue, Dec 17, 2013 at 3:01 PM, Rob Vesse <rv...@do...> wrote:
>> Kal
>> 
>> The basic installer looks fine since it just puts stuff on disk, ideally it
>> would also add command line shortcuts to the GUI tools to the Start Menu.
>> 
>> However personally I have been unable to build it so far, what I run into is
>> an error about the Bootstrapper not being found:
>> 
>> Could not find required file 'setup.bin' in 'C:\Program Files\Microsoft
>> SDKs\Windows\v7.0\Bootstrapper\Engine'
>> 
>> This mailing list thread
>> (https://www.mail-archive.com/wix...@li.../msg33513.html)
>> essentially seems to cover the problem I have which is that I have the
>> Bootstrapper files but only under C:\Program Files (x86) and not under
>> C:\Program files where WiX is looking
>> 
>> Have you ever run into this before?  Any idea how to fix it?
>> 
>> The above linked thread does have a suggested workaround but knowing nothing
>> about WiX I haven't attempted it because I'm not sure what the implications
>> of it are.
>> 
>> Btw work for integrating this into the solution is now on the TOOLS-360
>> branch where it's included in the main solution though not yet in NAnt
>> 
>> Cheers,
>> 
>> Rob
>> 
>> From:  Kal Ahmed <ka...@ne...>
>> Date:  Tuesday, 12 November 2013 16:38
>> To:  Rob Vesse <rv...@do...>
>> Subject:  Toolkit installer
>> 
>>> I've just pushed a couple of commits that add a basic version of the
>>> installer. The project file is
>>> Build\ToolkitInstaller\ToolkitInstaller.wixproj and there is also a VS
>>> solution file (VS2012 format) for it.
>>> 
>>> It should be possible to build from the command line as long as you have WiX
>>> 3.7 (or later) installed, and from VS if you have the necessary WiX votive
>>> stuff installed (all part of the WiX installer now I think).
>>> 
>>> All it does is put the files on the disk  - as far as I could tell that is
>>> all the original installer does, but if there are registry things or other
>>> things you need the installer to do, let me know.
>>> 
>>> Things to do :
>>> 
>>> 1) It currently builds to set the default install into
>>> ProgramFilesFolderPath which is "C:\Program Files" on x86 but is "C:\Program
>>> File (x86)" on x64. As far as I have been able to work out the only way
>>> around this with WiX is to build two versions of the MSI and wrap them in a
>>> bootstrapper that chooses the correct version based on installation
>>> platform. I've just done this for BrightstarDB and its horrible and adds
>>> another bit of random GUI to the process as well as doubling the installer
>>> size, so I haven't done that for now.
>>> 
>>> 2) Its not currently integrated into the NAnt build - I didn't want to mess
>>> with that until the WiX installer is considered OK
>>> 
>>> 3) I wasn't sure how to set the version number. Currently it is hard-coded
>>> in the .wixproj file as a Property (DotNetRdfVersion). If you can point me
>>> in the right direction for getting hold of the build number during the build
>>> process I can fix that up.
>>> 
>>> Cheers
>>> 
>>> Kal
>>> -- 
>>> Kal Ahmed
>>> Director, Networked Planet Limited
>>> e: kal...@ne...
>>> w: www.networkedplanet.com <http://www.networkedplanet.com>
> 
> 
> 
> -- 
> Kal Ahmed
> Director, Networked Planet Limited
> e: kal...@ne...
> w: www.networkedplanet.com <http://www.networkedplanet.com>