Relative path woes with wybuild.cmd.exe version 2.6.17.1

In wyBuild 2.6.17.1 we made wyBuild use relative paths so the project files would be more easily transferable from computer to computer. This should have absolutely no impact on your building process. However, it looks like something slipped by our tests.

I need a bit more information before I can reproduce this bug:

1. Where is the wyBuild project file located on the disk? (Can you give me the full path?)
2. Where is the Template_MyApp.exe.config file on disk? (I see one is specified at J:\Releases\Foo\Bar\ConfigurationFiles\ConfigTemplates\Template_MyApp.exe.config, is this the only one?)
3. Have you moved or are you moving the wyBuild project file around (*.wyp).
4. Have you moved or are you moving the files from any of your versions around?

Thanks for the quick response. To answer your questions:

1. Where is the wyBuild project file located on the disk? (Can you give me the full path?)

E:\BuildNewVersion\Build\ServerUpdate\Server.wyp

2. Where is the Template_MyApp.exe.config file on disk? (I see one is specified at J:\Releases\Foo\Bar\ConfigurationFiles\ConfigTemplates\Template_MyApp.exe.config, is this the only one?)

The full path you see here is where one copy of Template_MyApp.exe.config is. The other is located at E:\BuildNewVersion\Application\bin\Release\ConfigurationFiles\ConfigTemplates, from which it was copied onto my J: drive.

3. Have you moved or are you moving the wyBuild project file around (*.wyp).

No. The wyBuild project file is pulled from source control into the location cited in (1). We build every new version from a new folder just to ensure that we don't disturb any artifacts from a previous version's build.

4. Have you moved or are you moving the files from any of your versions around?

No. We keep the last several versions' output on the same drive (different folders) as the new version so that wyBuild won't have any trouble finding them. For example, our prior release would have been on J:\Releases\Eoo\Aar and our release after the one we're trying to build would go on J:\Releases\Goo\Car .

Let me know if there's anything else I can provide to help trouble-shoot.

I'll try to reproduce this now.

Having relative path issues as well:

C:\jberger\XML Tool\Build\XML Tool.wypC:\jberger\XML Tool\Build\Versions.xml (passed into wybuild.cmd.exe)C:\jberger\XML Tool\Build\Release\ (contains all files to be published)

Example "Path on disk:" C:\jberger\OurTool\Build\Release\AutomaticUpdater.xml

(Versions.xml)<?xml version="1.0" encoding="utf-8"?><Versions> <AddVersion> <Version>1.38.006</Version> <Changes>changed executable filename.</Changes> <InheritPrevRegistry /> <InheritPrevActions /> <Files dir="basedir"> <Folder source="Release" insideonly="true" /> </Files> </AddVersion> <RemoveVersion ver="1.38.005"/><!-- <AddVersion> MUST be BEFORE --></Versions>

Also, I don't see anywhere specifying whether relative or absolute paths are being used. Maybe "Path on disk:" could be changed to "Absolute Path:" or "Relative Path:" depending on the situation. (Relative Path would be shown relative to the .wyp file.) Also, if using relative paths, show the anchor path (.wyp file path) next to the Files and Folders header.

Thank you.

wyBuild automatically converts the absolute path to relative paths. What's the exact error you're getting?

wybuild.cmd.exe isn't creating relative paths for the project file. (It's creating absolute paths.)

We have a wybuild project file which we use wybuild.cmd.exe. Now, when all solution files (including wybuild project file) are pulled from the source code repository to a different location (e.g. a different developer's machine which has a different path); the Files & Folders paths resolve to the old, absolute path; and NOT relative to wybuild project file.

@ClearViewEdge

I'm not having any luck reproducing this problem. Can you make a simple example that reproduces this?

@bergerj

We have a wybuild project file which we use wybuild.cmd.exe. Now, when all solution files (including wybuild project file) are pulled from the source code repository to a different location (e.g. a different developer's machine which has a different path); the Files & Folders paths resolve to the old, absolute path; and NOT relative to wybuild project file.

Firstly, make sure you're all using wyBuild 2.6.17.1 (and not 2.6.17.0). We fixed a bug in 2.6.17.0 where the commandline builder wouldn't form the relative paths.

Next, make sure the paths are on the same logical disk as the project file. That is, if your project is on the C:\ drive, and your files are on the C:\ drive then relative paths will be formed. However, if your project is on a different logical drive then your files (e.g. project on C:\, files on F:\) then wyBuild will use the absolute paths of the files (because there's no "relative" way to get from C:\ to F:\ -- they're on separate drives).

I have done a little more digging to try to understand the issue.

I wanted to generate a small project that behaves like our production project, so I did the following:

--Created two folders on our release server that mirror our production folder hierarchy, one for version 1.0 of the test product and the second for version 2.0. Populated those with files to be included in the update, with the version 2.0 files guaranteed to be different from the version 1.0 files.

--Created a version 1.0 Server.wyp using the wyBuild 2.6.17.1 GUI and built it. Note that this project contains a representative subset of the files and folders in the production version.

--Created a small Test.xml project update file that's a subset of our production version and that uses absolute paths to all the files.

--Ran version 2.6.17.1 of wyBuild.cmd.exe from the root of my test build folder using the command line specified in my earlier postings. In this case, I was running on one machine (Build) with my current drive and folder being E:\BuildTest and the files to be compared and updated on a network share (machine Release, with a shared drive mapped as J:)

In this scenario, it ran just fine. I then took a copy of my Test.xml file, changed the file paths and version number to reflect our production release and put it in the production build folder (e.g. E:\BuildVersion2\Build\Server). I ran version 2.6.17.1 of wyBuild.cmd.exe from the root of my production build folder using the Test.xml and my production .wyp file, and it failed.

The key difference that I see here is that my production .wyp file that I was trying to update was built using the previous wybuild.cmd.exe version (2.6.16.4, I believe) whereas the test project version 1.0 was built using the wyBuild GUI version 2.6.17.1.

I haven't yet tried reverting to the prior version of the command line builder, but I think that might be instructive.

I've had a breakthrough and can now build successfully. It appears that the error message I was getting was deceiving me.

It turns out that what I didn't know while I was looking at this issue is that our system admin had zipped up the source files from several of the earlier versions in our .wyp file. Therefore, wybuild.cmd.exe was trying to report, correctly, that it couldn't find the source file in the earlier version to compare to the one in the new version we were adding. However, the error message I was getting didn't say "Cannot find <path to earlier version>\<source file>, but said "Cannot find <path to project file>\<source file>.

As long as I specify the start version on the command line as one whose files are actually there, the build works fine. I've verified this with a 2.6.14.0 version and with 2.6.17.1. I will either adjust our build process, or remove the old versions from the .wyp file.

Wyatt, thanks for the time and effort you've put into this issue.

1. Yes, using 2.6.17.1

2. Yes, they're on the same drive. Please see my first post for the old locations and new locations.

(Win 7, Ultimate N, SP1, 64-bit)

I've reproduced it. It's not easy and I don't know the exact steps, but here's a little something-something..

http://www.sendspace.com/file/o8zwyj

@ ClearViewEdge

I'm glad you found the solution. We're going to make this easier to debug with better error messages.

@bergerj

I'll look into this.

@bergerj

We can reproduce your problem. The problem was caused by wyBuild not correctly expanding the project filename that you passed into the commandline builder. We'll fix this in the next version of wyBuild.

In the meantime, make sure you pass in the entire directory for the wyBuild project file. That is, this:

wybuild.cmd.exe "C:\Path to\Your\Relative Path Errors.wyp" /bu /bwu -add="Versions.xml"

Instead of this:

wybuild.cmd.exe "Relative Path Errors.wyp" /bu /bwu -add="Versions.xml"

I wanted to leave a comment:

Using 2.6.18.4, when trying to add a version from cmd, I've found that the path parsing is still fussy:

This does not work (I.E. files are added to the project that can't be found):C:\Program Files (x86)\wyBuild\wybuild.cmd.exe c:\\code\packaging\..\deployment\product\updates\product.wyp /bwu -add="c:\code\package\wyupdate\7.7.7.7.xml"

While this does:C:\Program Files (x86)\wyBuild\wybuild.cmd.exe c:\\code\deployment\product\updates\product.wyp /bwu-add="c:\code\package\wyupdate\7.7.7.7.xml"

Hopefully this saves folks a bit of time 🙂