Selection of the source folder for a project - Handle web projects dealing with "PublishedWebsite"

[Leogiciel]

Hi, and thank you for the great work 👍

Output (in TargetDir folder) for WebAPI and MVC projects are different than real published content :

• Content folders are not copied into bin folder but are taken from sources in debug

• Some of the references are not published when option "Only files needed to run this application" is selected in project publish web preferences

These two VS behaviours imply we have to manually make many changes to wxs file, which will be lost if it is generated again.

It would be great if, by an option, we can select the publishedWebsite folder for these projects.

[tom-englert]

Wax relies on the Visual Studio project model - it simply collects what VS reports as project output, it does not scan any output folder. So I see no option to select the publishedWebsite folder. Wax also can't reflect additional tweaking done by the publish build step, since this also won't appear in the VS project model.

If just the project output is different in debug and release configurations, you should edit and build the installer only when the release configuration is active.

If you just want to dynamically collect anything from a specific output folder, maybe the tool of your choice is heat

[Leogiciel]

Thanks for your reply, I was almost sure of your answer... We used to use Paraffin to generate wxs file from a folder, but I want to keep Wax naming : Paraffin generates guid-like Ids for the files, and I prefer your Ids (based on file name).

Do you know if heat can handle that ?

[tom-englert]

No, I think heat also uses guids that change with every run... To keep the the wax naming a standalone version of wax that just scans a folder would be needed.

[Leogiciel]

I've found a solution :

1. I mark every content files as "Copy always" to not miss any of them (web.config by example, loosing release build transformation)

2. I move dlls and pdbs components in the ComponentGroup which points to bin folder.

3. I remove "bin\" in the source path of dll and pdb of the main assembly

It's a five minutes operation, that's pretty cool. Publishing site is no more necessary in TFS build process.

Maybe I'll try to make a "Web" version of Wax to automate this process in a postbuild event, and to understand how Wax locates the files where Components are generated (I've many wxs files in my project, one by installer work). I'll inform you.

Off-topic : the extension seems to be automatically disabled each time I open VS 2015. Do you know this behaviour ?

Thanks again anyway Regards

[tom-englert]

The "disabled" problem is probably the same as this: https://resxresourcemanager.codeplex.com/workitem/4730, it's a known bug in the VS extension installer, sometimes leaving old versions behind. (or try https://github.com/remcoros/DuplicateExtensionFinder)

Wax is just a design time tool, the idea is to keep the files in the .wxs files up to date at design time - it is not involved in the post build step.

However I could think of some special handling of content files in special folders, if the project is a web site project.

Maybe you can send me a sample project, so we are talking about the same project kind?

[Leogiciel]

WebAPI.zip

There you are.

My main problem is principal assembly dll is taken from TargetDir\bin (and not TargetDir) and other references are not going into bin but only into INSTALLFOLDER :

<File Id="bin_WebAPI.dll" Name="WebAPI.dll" Source="$(var.WebAPI_TargetDir)bin\WebAPI.dll" />

(should be $(var.WebAPI_TargetDir)WebAPI.dll)

`

` (should be into bin folder) Also, some references are duplicated in the output, and some of the content files are detected by Wax but won't go to bin until I set them as "CopyAlways" (Global.asax, web.config...) Thanks for the DuplicateExtensionFinder tool by the way, you were right 👍

[Leogiciel]

New deal : I use this nuget package which delivers four dlls but references only the top two of them in the csproj. (see my post on SO explaining this behaviour).

VS and MSbuild both do right at compilation, detecting types from other two libraries, and the four libraries are in the bin folder.

Wax doesn't detect them, and I understand that's because it's based on csproj file, but if MSBuild can do it maybe we can too ?

Regards

[Leogiciel]

Thanks, I'll open a new issue for second-tier references.

I've downloaded your code, I'm debugging it, and I wonder if we can handle them like MSBUILD does.

[Leogiciel]

@tom-englert : Thats only a partial fix.

Main dll is not now taken from TargetDir and not from TargetDir\bin anymore, but as every dlls and pdbs they must go into INSTALLDIR\bin folder (and not only INSTALLDIR) once deployed.

"My main problem is principal assembly dll is taken from TargetDir\bin (and not TargetDir) and other references are not going into bin but only into INSTALLFOLDER :

<File Id="bin_WebAPI.dll" Name="WebAPI.dll" Source="$(var.WebAPI_TargetDir)bin\WebAPI.dll" />

(should be $(var.WebAPI_TargetDir)WebAPI.dll) ==> FIXED 👍

<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER"> <Component Id="Microsoft.ApplicationInsights.dll" Guid="5be45e3e-bc09-4522-a8fd-a875a83a0bf4"> <File Id="Microsoft.ApplicationInsights.dll" Name="Microsoft.ApplicationInsights.dll" Source="$(var.WebAPI_TargetDir)Microsoft.ApplicationInsights.dll" /> </Component>

(should be into bin folder) ==> NOT FIXED 👎 "

[tom-englert]

Wax does not deal with directories - if the default install dir that comes with the default template provided by the WiX Toolset (not Wax) does not suite your needs, you have to prepare the directory structure in the .wxs file, and select the proper target dir before adding any files... (you have to select this in step (2))

[Leogiciel]

The root directory is good. I select it at step 2, and some files are placed by Wax inside it as needed (eg : web.config, Global.asax, subdirectories....)

The only point is that for ASP .Net applications, the deployment implies that every dlls and pdbs (including main assembly ones) are published in an hard-coded "bin" folder, inside the root folder, and not in the root folder like other project types.

That's why you saw a hard-coded bin for main assembly library : that's wrong for the source (every dlls are built in the TargetDir), but right for the target (every dlls must go in a hard-coded bin folder under target directory).

Make a "Publish website" on the project I sent you, and you'll saw the final architecture needed for every ASP.Net applications.