55

Closed

Support Visual Studio (XDT) Web.config Transforms

description

Currently, we have the auto-magical simple web.config transforms. We want to support allowing package authors to opt-in to using VS Web.config transforms.

This depends on this feature being put in the runtime framework before NuPack can depend on it.
Closed May 13 at 6:36 PM by danliu

comments

Dogtail9 wrote Oct 24, 2010 at 9:35 AM

It would be great to add XSL support while we wait. XSLT is supported by the framework.

public static void Transform(string sXmlPath, string sXslPath){ 
    try{
        //load the Xml doc
        XPathDocument myXPathDoc = new XPathDocument(sXmlPath) ;
        XslTransform myXslTrans = new XslTransform() ;
        //load the Xsl 
        myXslTrans.Load(sXslPath) ;
        //create the output stream
        XmlTextWriter myWriter = new XmlTextWriter(sXmlPath, null);
        //do the actual transform of Xml
        myXslTrans.Transform(myXPathDoc,null, myWriter);        
        myWriter.Close() ;
    }catch(Exception e){
        Console.WriteLine("Exception: {0}", e.ToString());
    }
}

Dogtail9 wrote Oct 24, 2010 at 10:35 AM

Upps! XslTransform is deprecated. XslCompiledTransform is the class to be used.

nblumhardt wrote Jan 24, 2011 at 8:57 PM

This is needed to support the addition of binding redirects to config files, as the <assemblyIdentity> and <bindingRedirect> elements must appear beneath their own unique <dependentAssembly> parent. By merging (current behaviour) the identities/redirects all get merged under a single parent.

Cheers,
Nick

Haacked wrote Mar 23, 2011 at 4:51 PM

Notes copied from Issue 711 - Dupe of this one:

As a package author, I'd like to be able to author a simple XDT transformation (which is quite a bit more flexible and powerful than the built-in .transformation currently supported), have it applied on install, and rolled-back on uninstall.

So the support would need to:
  • On install, do a pass on the transformation, and generate (ideally) another XDT that can be used to undo the changes (i.e. revert attribute values to what they had before, etc.)
  • Perform the transform
  • On uninstall, apply the undo XDT to the files as appropriate.
Package installation folder would need to keep a map of applied transformations and their undo XDT to apply on uninstall.

Haacked wrote Apr 28, 2011 at 7:57 PM

@nblumhardt how important is this bug to you now that we automatically manage binding redirects for you when you install a package?

James_2JS wrote May 3, 2011 at 8:47 AM

Hi Phil,

I'm interested in this, but not for the bindingRedirect.
It allows a whole host of configuration changes that just aren't possible right now.

Cheers,

James

nblumhardt wrote May 3, 2011 at 10:27 PM

@haacked I don't think this is an issue for me any more (though I haven't done much with XML config in the last few months.)

Cheers,
Nick

dotnetchris wrote Jun 14, 2011 at 5:28 PM

+1, i basically duplicated this issue on http://nuget.codeplex.com/workitem/1189 because I thought it was supposed to merge elements

dotnetchris wrote Jun 14, 2011 at 5:36 PM

@Haacked reading your comment you wrote Mar 23 at 12:51 PM that is absolutely what I'd like to see happen with config transforms in nuget!

James_2JS wrote Apr 13, 2012 at 11:12 AM

Is there any news on this one?
I too agree with dotnetchris in stating that Haacked's comment of Mar 23 2011 would be perfect.

I believe that the latest release of ELMAH (1.2.2) is going to give us issues.
We addressed issue http://code.google.com/p/elmah/issues/detail?id=253 requesting that we add a configuration parameter to mimic the default behaviour so that users know where to make a change.
This now breaks anyone who installed previous versions of the package and manually added the parameter in.

RichardHauer wrote Apr 30, 2012 at 3:52 AM

Very interested in this - I want to use NuGet to deploy componentised solutions for Sitecore CMS and I need the ability to deliver configuration to a precise location (as in, after this element but before this one).

dotnetjunky wrote Jul 10, 2012 at 7:10 PM

We're exploring the possibility of supporting XDT. Stay tuned.

dotnetjunky wrote Aug 13, 2012 at 6:06 PM

To update everyone on this issue. Due to resource constraint, we will have to delay this feature until 2.2. The feature has been implemented, but we need more time to test.

JeffHandley wrote Jan 23 at 8:37 PM

Triage: moved into 2.3 due to high vote count.
This is not a guarantee that it will be completed in 2.3 though. We are blocked on the open-sourcing of the XDT library.

dotnetjunky wrote Mar 12 at 5:01 PM

I assign to you to verify when you have bandwidth.

Sign in to add a comment