On Wed, May 7, 2014 at 11:52 AM, Bob Arnson <b...@joyofsetup.com> wrote:
>
> On 07-May-14 12:14, Eric Schultz wrote:
> > So, I've been working on a cleanup of the Votive to try to mesh it
> > with the Python Tools for Visual Studio as much as possible.
>
> I'll donate an entire month's WiX salary plus bonus to the cause!
That's so generous of you :) Indicating that it's useful too really helps.
>
> > - Is having a solution file something we should have as a goal?
>
> Yes, with priority in line with how much it helps you. Is the
> SharedProject stuff causing the problem?
What isn't causing the problem? :) We need the Wix.dll, plus its
dependencies built, to build Votive. To do that from a Solution file, we
need the Wix project and their dependencies included in the solution. Doing
that causes the first build of Wix after a clean to fail, but, don't
worry, it works the second time. That's probably easily fixable but I
haven't gotten to it yet. Then Votive VSIX (or it's MSI equivalent) should
include the Wix.dll since it's a dependency. That causes an issue though
because the output of the Wix project includes an Xsd file and the
DetokenizeVsixManifestSource build task in the DetokenizeVsixManifestFile
target doesn't know how to handle that (it tries to get it's Assembly
Fullname and then fails). I tried to create a Task to run before
DetokenizeVsixManifestSource to strip out the XSD files from it but I'm now
taking too much out (again, still trying to figure it out). There's some
other problems that aren't coming to mind right now.
The code builds if you eliminate the solution file and the changes that are
required to make it "almost" work in the solution file. Either way, fitting
it into the Wix build process is difficult and rather touchy. If you don't
do things exactly right, things won't build and it's really confusing as to
why.
>
> > - Is supporting the standard debug in VS scenario for Votive important?
>
> The whole debug-a-package scenario is pretty non-standard...
Really? I've done it and it's very nice to use.
>
> > - Should Votive be installed at the system level, thereby requiring a
> > developer to uninstall the official version of Votive (but not the Wix
> > dlls somehow because we need those) in order to debug, or should we
> > figure out a way for Votive to install at the user level? This would
> > probably require the relevant the parts of the Wix API used in Votive
> > be installed at the user level with Votive.
>
> When Votive started, VSIXs weren't an option. It would probably work
> fine as a VSIX though some things like templates assume a per-machine
> install of WiX (toolset and MSBuild). The old-school "experimental hive"
> was the solution for having a package in your normal instance of VS and
> developing it in the Exp instance. Maybe these days it's having multiple
> versions of VS side-by-side...
When you build a VSIX, it should install into the Experimental hive. That
only works though if Votive isn't installed at the system level already
though. To uninstall Votive, you uninstall the Wix bundle and uninstalls
Votive in all your instances of VS PLUS all the Wix assemblies. That means
your experimental version of Votive at the user level doesn't really work
properly anymore. If it's done at the system level, you have to go through
the wix bundle installer which is not quick. (there's probably a way to do
that using the individual MSIs to make it faster but even then, I can't
imagine it'll be quick).
>
> I'm all for making whatever changes make it easier to develop Votive,
> but not if it makes you crazy first. :)
I think I'm already there.:)
I think it'd be easier if Votive was in a totally different repo and
depended on Wix like a third party component would. Whether that's via Wix
shipped as a NuGet package which your VSIX and templates use (that'd be
slick if it worked well) or if it just uses the tools from Program Files, I
think it'd make developing Votive simpler. You wouldn't have to worry that
you need to modify something like WixBuild.targets or WixBuild.props or
override it. It's just a lot of things to consider when you make changes to
the build process for Votive because it has unique needs that are quite
different from all the other tools. It might also simplify the dependencies
for doing hacking on the other Wix tools (not sure). All that said, while
it may look like a great idea to me now, once I actually get into it, I
guarantee there will be headaches that I'm not foreseein
>
> --
> sig://boB
> http://joyofsetup.com/
Thanks for the advice so far. This really does help, especially morale :)
Eric
---------
Eric Schultz, Developer Advocate, Outercurve Foundation
http://www.outercurve.org
eschu...@outercurve.org
cell: 920-539-0404
skype: ericschultzwi
@EricOutercurve
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs