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

Support transform content files (xml and .pp) #614

Open
2 tasks
tpluscode opened this issue Feb 17, 2015 · 13 comments
Open
2 tasks

Support transform content files (xml and .pp) #614

tpluscode opened this issue Feb 17, 2015 · 13 comments

Comments

@tpluscode
Copy link
Contributor

tpluscode commented Feb 17, 2015

Hi

It would be nice to support the config transform files like for example Microsoft.AspNet.Mvc package does to bootstrap web.config for MVC projects. Those files (.install.xdt and .uninstall.xdt) should also never be added as content

Thanks,
Tom

Transform files (ref https://docs.nuget.org/create/configuration-file-and-source-code-transformations ):

  • xml
  • .pp
@forki
Copy link
Member

forki commented Feb 18, 2015

What would we have to do?

@tpluscode
Copy link
Contributor Author

The general scenario is that for each file xxx.xml.install.xdt and xxx.xml.uninstall.xdt it should be applied to xxx.xml during installation and uninstallation respectively. When the file is not present I think it could be created though I'm not sure it will be possible, because paket won't know the root node to insert. So maybe a warning will be enough when the file to be transformed is missing.

The problem may be that paket installs packages every time thus applying the install.xdt multiple times. Would it be possible to run the transformation only the first time a package is added to a project?

@Saeverix
Copy link

Need support for XDT transforms also. Because it's a crucial part in the Microsoft.AspNet.Mvc package. Installing version 4.0.0.1 of Microsoft.AspNet.Mvc ensures that the Web.config of the project gets a BindingRedirect from 1.0.0.0-4.0.0.1 to version 4.0.0.1. Using Paket the BindingRedirect will not be installed resulting in a "Could not load file or assembly" error. Please add/fix this.

@tpluscode
Copy link
Contributor Author

@wernerdev for now you can have paket install binding redirects

paket.exe install --redirects

@Saeverix
Copy link

That is no solution for me because it will add BindingRedirects for all packages, which causes other problems.

Can you then add an option to paket.dependencies or paket.references to set redirects: on for individual packages? So that I can enable it for Microsoft.AspNet.Mvc only in my case.

@isaacabraham
Copy link
Contributor

@wernerdev There's an up-for-grabs for that somewhere I think i.e. per-package BRs (or was it per-project?). I'm curious - what other problems do you get when the binding-redirects flag is on?

@Saeverix
Copy link

For example with System.Net.HTTP 2.2.29 the following Reference is added without Hintpath to the packages folder:<Reference Include="System.Net.Http"> <Paket>True</Paket> </Reference>

(I tried removing all References and re-adding them trough paket.exe install --hard but that did not fix/add the Hintpath.)

So in that case IIS and VisualStudio automatically gets the latest version from my system which is version 4.0.

When adding BindingRedirects with Paket it will add a oldVersion="0.0.0.0-2.2.29.0" redirect, which is not detecting version 4.0 and thus making my project fail because it cannot find the version specified by the BindingRedirect.

@baronfel
Copy link
Contributor

Ah, so now we've crossed over into the 'how do we want paket to handle framework dependencies' question. @wernerdev the package in question doesn't ship a version of System.Net.Http, rather it just includes a reference from the GAC. So before paket can add a redirect for this, it would need to be taught how to interpret system references.

@Saeverix
Copy link

The System.Net.Http assembly is from the Microsoft.Net.Http package (https://www.nuget.org/packages/Microsoft.Net.Http/)

As you can see the lib folder for net45 does not have a System.Net.Http.dll file. So in that case it will indeed use the system assembly. net40 does have it's own System.Net.Http.dll file.

But what I am trying to say here is that the way Paket handles Redirect for all packages is causing issues. Issues that won't be there if the normal NuGet transforms are being supported by Paket, or if you allow a package specific "Add references" setting.

@jamesjrg
Copy link
Contributor

jamesjrg commented Nov 1, 2015

I was taking a look at how difficult it might be to add xml transforms specifically for app.config/web.config files. This leads to various questions!

1:

Why is it that the binding redirects code searches for paket.references and then assumes app.config/web.config files need to live alongside those paket files, rather than assuming app.config/web.config files should live alongside project files?

Perhaps naively it seems that a method could be added to the ProjectFile class to search for any existing app.config or web.config (or even both) alongside the project file on disk. Then early on in the install process, if the "create config files" option (currently named CreateNewBindingFiles) is set to true, any projects missing accompanying config files could create them.

Then during the processContentFiles step any [app|web].config.install.xdt files could be applied to each config file.

Then finally the existing binding redirects code could run, but using the new method on the ProjectFile class to find the config file to transform rather than doing its own search files/create files logic.

Possibly @isaacabraham knows reason this isn't possible.

On top of this, ideally uninstall xdts for app/web.config files would be applied during removal of packages, but I've not looked into that yet. Also ideally all this transform stuff would handle xml transforms for other types of files, and even .cs.pp transforms (#1139), but again I've not been thinking about that.

Question 2 is regarding packages which have already been installed:

If an xdt transform attempts to add an element that already exists, it is idempotent, so it may be that it is fine to run transforms on every paket install execution, without worrying if they have already run before. Is there some reason this approach isn't reasonable?

Another option: when findNuGetChangesInDependenciesFile is called early on in the paket process, it calculates which packages are newly being newly installed or updated and which are unchanged. If this information were threaded all the way through to the final part of the install where content files and redirects are handled, these could be run only for new/changed packages, not run every time, but maybe there are reasons this isn't a good idea either?

@matthid
Copy link
Member

matthid commented Jun 15, 2017

Related #2231

@enricosada
Copy link
Collaborator

from #1139 (comment)

its described in the "Source Code Transformations" and "Specifying Source Code Transformations" sections at
https://docs.nuget.org/create/configuration-file-and-source-code-transformations

@enricosada enricosada changed the title Support xml transform content files Support transform content files (xml and .pp) Jan 24, 2018
@mzhukovs
Copy link

mzhukovs commented Jun 3, 2018

I can't for the life of me get this to work (creating a nuget package that will copy over one .cs.pp file and some static assets into the target project that installs the package) - can anyone please help by providing a simple VS2017 project that is all set up to package the nuget that would achieve this? Would be much appreciated.

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

No branches or pull requests

9 participants