Menu
▾
▴
dotnetrdf-develop
|
From: Rob V. <rv...@do...> - 2013-12-17 15:02:53
|
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> |
|
From: Rob V. <rv...@do...> - 2014-02-13 11:46:57
|
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> |
|
From: Rob V. <rv...@do...> - 2014-02-13 11:59:27
|
After a bit more digging I figured out how to change the directory things are placed into so I have that figured out. Next up is being able to select precisely which tools are installed Rob From: Rob Vesse <rv...@do...> Reply-To: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Date: Thursday, 13 February 2014 11:46 To: Kal Ahmed <ka...@ne...> Cc: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Subject: Re: [dotNetRDF-Develop] Toolkit installer > 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> > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 > Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview > and more. Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk__ > _____________________________________________ dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
|
From: Khalil A. <ka...@ne...> - 2014-02-13 12:53:46
|
Cool! Happy to help out when I can, but I'm currently working on-site for a customer, so my time is a bit limited at the mo. :-( Choosing what to install is a question of dividing up the features. You may also need to change the UI used by WiX to one that displays the feature tree to the user. Let me know if you want me to take a look. By the way, I'm working on adding Xamarin support to the portable build of B*. For now I'm building local versions of vds-common and DNR. Once I have something working we could maybe look at updating the builds and nuget packages, but I'll aim to get stuff working and do a few integration tests first. Cheers Kal On 13 Feb 2014 11:59, "Rob Vesse" <rv...@do...> wrote: > After a bit more digging I figured out how to change the directory things > are placed into so I have that figured out. > > Next up is being able to select precisely which tools are installed > > Rob > > From: Rob Vesse <rv...@do...> > Reply-To: dotNetRDF Developer Discussion and Feature Request < > dot...@li...> > Date: Thursday, 13 February 2014 11:46 > To: Kal Ahmed <ka...@ne...> > Cc: dotNetRDF Developer Discussion and Feature Request < > dot...@li...> > Subject: Re: [dotNetRDF-Develop] Toolkit installer > > 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 >> >> > > > -- > Kal Ahmed > Director, Networked Planet Limited > e: kal...@ne... > w: www.networkedplanet.com > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 > Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, > Mapview and more. Get your Android app in front of a whole new audience. > Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > |
|
From: Rob V. <rv...@do...> - 2014-02-13 12:57:36
|
Yeah I've already made some progress on getting features selectable, haven't refactored the project to include all features yet or get the default feature set for custom installations behaving correctly yet but am making progress Once you have stuff for xamarin builds then we should definitely integrate that for dotNetRDF and VDS.Common Cheers, Rob From: Kal Ahmed <ka...@ne...> Reply-To: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Date: Thursday, 13 February 2014 12:31 To: dotNetRDF Developer Discussion and Feature Request <dot...@li...> Subject: Re: [dotNetRDF-Develop] Toolkit installer > > Cool! Happy to help out when I can, but I'm currently working on-site for a > customer, so my time is a bit limited at the mo. :-( > > Choosing what to install is a question of dividing up the features. You may > also need to change the UI used by WiX to one that displays the feature tree > to the user. Let me know if you want me to take a look. > > By the way, I'm working on adding Xamarin support to the portable build of B*. > For now I'm building local versions of vds-common and DNR. Once I have > something working we could maybe look at updating the builds and nuget > packages, but I'll aim to get stuff working and do a few integration tests > first. > > Cheers > > Kal > > On 13 Feb 2014 11:59, "Rob Vesse" <rv...@do...> wrote: >> After a bit more digging I figured out how to change the directory things are >> placed into so I have that figured out. >> >> Next up is being able to select precisely which tools are installed >> >> Rob >> >> From: Rob Vesse <rv...@do...> >> Reply-To: dotNetRDF Developer Discussion and Feature Request >> <dot...@li...> >> Date: Thursday, 13 February 2014 11:46 >> To: Kal Ahmed <ka...@ne...> >> Cc: dotNetRDF Developer Discussion and Feature Request >> <dot...@li...> >> Subject: Re: [dotNetRDF-Develop] Toolkit installer >> >>> 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.htm >>>>> l) 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> >>> ---------------------------------------------------------------------------- >>> -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 >>> Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, >>> Mapview and more. Get your Android app in front of a whole new audience. >>> Start now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >>> _______________________________________________ dotNetRDF-develop mailing >>> list >>> dot...@li...https://lists.sourceforge.net/lists/l >>> istinfo/dotnetrdf-develop >> >> ----------------------------------------------------------------------------->> - >> Android apps run on BlackBerry 10 >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >> Now with support for Jelly Bean, Bluetooth, Mapview and more. >> Get your Android app in front of a whole new audience. Start now. >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >> _______________________________________________ >> dotNetRDF-develop mailing list >> dot...@li... >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 > Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview > and more. Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk__ > _____________________________________________ dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X