Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Leogiciel opened this issue Dec 28, 2016 · 11 comments · Fixed by #16

Comments

@Leogiciel
Copy link
Contributor

Leogiciel commented Dec 28, 2016

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
Copy link
Owner

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
Copy link
Contributor Author

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
Copy link
Owner

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
Copy link
Contributor Author

Leogiciel commented Dec 30, 2016

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
Copy link
Owner

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
Copy link
Contributor Author

Leogiciel commented Jan 2, 2017

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)

<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)

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

Leogiciel commented Jan 3, 2017

@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
Copy link
Owner

tom-englert commented Jan 3, 2017

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants