tokenize.ps1 fails to selectsinglenode without namespace

[johndpalm]

I'm trying to use the Tokenizer against a SharePoint app manifest.xml file. SelectSingleNode (line 57) fails since there is a name space. I think if you test for NameTable or NamespaceURI you can support this with little code change:

$ns = New-Object System.Xml.XmlNamespaceManager($xmlraw.NameTable) $ns.AddNamespace("ns", $xmlraw.DocumentElement.NamespaceURI) $xmlraw.SelectSingleNode("//ns:$($key.KeyName)", $ns)

[pascalberger]

@johndpalm Depending on what you need to patch in the SharePoint app manifest, we have created a build task which allows to set the URL & ClientID in the app manifest. You can find the extension here.

[incarnate]

Just to note we've experienced the same issue when trying to do a replace with NLog configurations in Web.config as it is namespaced.

Happy to submit a fix along the lines of John's suggestion above, however I wasn't sure on how the move to the new Powershell/VSTS SDK has progressed (#29)

[pascalberger]

@incarnate There exists a branch which I assume is related to #29: https://github.com/openalm/Extension-UtilitiesPack/commits/features/vsts-new-sdk-port.

But unfortunately there was no interaction here in any branch, PR or issue from any member / MSFT employee in the past 2 months...

[incarnate]

I'd noted the same @pascalberger :-(

Paging @harshil93 - is this extension still being updated or maintained?

[incarnate]

I've got a fix for this ready, just waiting on #50 to be merged.

I've added an option for two extra parameters to the JSON file so that the namespace can be set, like so:

  {
    "KeyName": "/configuration/ns:nlog/ns:targets/ns:target[@name='email']",
    "Attribute": "to",
    "value": "logs@test.com",
    "NamespaceUrl": "http://www.nlog-project.org/schemas/NLog.xsd",
    "NamespacePrefix": "ns"
  }

[harshil93]

@incarnate I have updated the extension to use the latest sdk and it now supports secret vars too. I won't put it on marketplace because of some compat reasons. You can pull in the source code and package it under your own private publisher name and install it. It will require the new coreclr agent with version >= 2.104.2 to work.

[pascalberger]

@harshil93 Does this mean version on the marketplace never will be updated?

[incarnate]

Thanks for the update @harshil93 - I should have time to submit a PR for this later in the week.

I echo Pascal's question on if/when this will be one the marketplace, I thought bumping the major version number would protect the existing installs & configurations.

[harshil93]

@incarnate @pascalberger The problem with updating it on the market place is that, it has a dependency on the new agent. Some of the Hosted Agents are still on the old agent. They should be updated to the new agent in a couple of weeks and after that I will release it to the market place.

I will try the logic of bumping major version, but I don't think its gonna work. At max it would be a couple of weeks of waiting.

Sounds good ??

[incarnate]

Sounds good to me, I didn't realise the limitation was the hosted agents. Since we're using hosted agents I'll hold off on deploying this as well.

[harshil93]

@incarnate Closing this. You can go ahead and fix this issue as the new sdk port is done.

[incarnate]

Thanks @harshil93 - please see PR #54 for this fix