When I first started writing IsWiX, I intentionally decided to keep it simple and keep the bar low for would be contributors. I decided to expose the in memory document as a raw XDocument to the designer (UI). This has worked out well but now I'm starting to realize what is really needed.
I've been getting irritated with InstallShield lately because I keep finding gaps in their automation interface. Now that I'm getting really serious with WiX, I've come to realize that WiX is practically lacking an automation interface. ( The .NET 1.1 CodeDomReader isn't very helpful.) WiX is a pretty decent schema and compiler but the fetish for NotePad++ has left some pretty big holes up the stack. While I understand my UI designers for WiX aren't for everyone, I'm pretty sure more people would be interested in a decent automation interface.
So I'm going to pause my development on IsWiX until I can come up with a good design that allows me to expose an automation interface for WiX separate from IsWiX and also work with Fireworks through some form of dependency injecting.
I have some technical debt to work off here. I'll get working on the automation interface so that the UI can follow. Course it would be really cool if the WiX team would write one themselves that way they could influence the authoring decisions made by third party tools.
2 comments:
Tim Owers orginally left the following comment. I accidentally clicked delete so I am reposting it.
Chris,
When you get back onto IsWiX, I have a lil' problem for you.
Loading a project from a folder that contains spaces via the VS plugin, causes an error whereby the spaces in the folder path is being seen as the end of the path:
The actual path is:-
C:\Users\Tim\Documents\Visual Studio 2008\Projects\TimsFirstTest\Product.wxs
and you can see from the err msg where it gets chopped.
---------------------------
System.IO.FileNotFoundException: Could not find file 'C:\Users\Tim\Documents\Visual'.
File name: 'C:\Users\Tim\Documents\Visual'
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials)
at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings settings, XmlParserContext inputContext)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings settings)
at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options)
at System.Xml.Linq.XDocument.Load(String uri)
at FireworksFramework.Managers.DocumentManager.OpenFilePath(String filePath)
Tim,
I'm sorry, I must not be escaping the path when passing it on the command line. I never detected this because I never use white space in my workspace paths.
How's your .NET skills? If you'd like you can submit a work item on CodePlex and even a Patch diff. Otherwise I hope to get to this for you sooner then later.
Also the VS integration is mostly to encourage proper behavior from my developers. I want them opening the solutions to give them a chance to verify everthing builds before and after they make changes. You can also just associate the File Extension with Visual Studio and IsWiX and take a shortcut that way. I actually allow myself to break the rules and usually work that way depending on what I'm doing.
Post a Comment