Robert Seso's Blog

Pages

Tuesday, May 26, 2015

So it's middle of the night, you are sitting at the customer's site trying to load test the production environment and need to quickly add a new test agent to the test rig to enable more concurrent users for your load test. No problem, you'd think, it's all described at https://msdn.microsoft.com/en-us/library/hh546459.aspx. So you follow the instructions there, double check all the settings, IP numbers, ports, firewalls, service accounts and their permissions and finally start the Microsoft Visual Studio Test Agent Configuration Tool to finish the configuration and add register the new agent with the controller.

You enter all the correct data, double check you entered the correct data, click on the "Apply Settings" and after all the fuss all you get is this exception in the log file:

I, 2015/05/27, 00:18:33.195,
CreateControllerObject: attempt 0, System.Net.Sockets.SocketException
(0x80004005): No connection could be made because the target machine actively
refused it 127.0.0.1:6901

at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage
msg)

So in this example 10.58.203.102:6901 is the correct IP address and the port number of the test controller you entered (and doublechecked) on the Test Agent Configuration Tool screen, but for some reason the agent ignores it and attempts to connect to itself at 127.0.0.1:6901. There's nothing on the agent listening at this port, thus the exception.What's the problem you might ask.The hosts file.That's right, the hosts file. The guy at C:\Windows\System32\Drivers\etc.

You open this file and find something like this in it:

127.0.0.1 crl.microsoft.com

It's actually not important what URL was mapped to 127.0.0.1 there, as soon as you have ANY URL mapped to 127.0.0.1 in the hosts file you'll get the exception above.

Why? I have no idea. We used the IP and not name or the FQDN of the controller in the agent configuration, so it didn't have to do any DNS name resolution at all, but it did. And even then, our controller IP address was not mentioned anywhere in the hosts file, so go figure.So how to solve it? Simply remove all the mappings for the 127.0.0.1 from the hosts file on the agent and try to register the agent again (restart the agent service to make sure it gets the new hosts file). It should connect now or at least bring some other exception.

And before you go - do the same on the test controller or you might get similar exceptions there.

Tuesday, July 16, 2013

SharePoint 2013 introduces the new app model making it possible to integrate externally hosted apps into SharePoint. One of the features of the new app framework is the so called “Chrome Control” which enables the externally hosted apps to dynamically load the SharePoint CSS and thus implement the same look and feel as SharePoint. There is a nice example on how to use the Chrome Control at http://msdn.microsoft.com/en-us/library/fp179916.aspx, so I will not go into the basics here. Rather, I want to point you to a nasty bug in the current SharePoint 2013 version which might affect you if you are loading the Chrome Control declaratively.

Note: you only need the Chrome Control in your provider or autohosted apps that run outside of the SharePoint context. You don’t need the Chrome Control in the SharePoint hosted apps since those run in the SharePoint context and can reference the necessary styles by referencing the SharePoint master page.

A little bit of background first. There are two ways to load the Chrome Control into your app: the JavaScript way and the declarative way.

The JavaScript way to load the Chrome Control looks something like this: first you need a page in your app with a placeholder that will host the Chrome Control once it’s loaded, e.g. (removed details for simplicity):

...

<bodystyle="display: none">

<formid="form1"runat="server">

<!-- Chrome control placeholder -->

<divid="chrome_ctrl_container"></div>

<!-- The chrome control also makes the SharePoint

Website stylesheet available to your page -->

<h1class="ms-accentText">Main content</h1>

<divid="MainContent">

</div>

</form>

</body>

...

In this case I have a <div id=”chrome_ctrl_container”> tag where the Chrome Control will be loaded. Once you have this, you can easily load the Chrome Control using JavaScript like this:

1:var SPWorkshop = window.SPWorkshop || {};

2:

3: SPWorkshop.ChromeControl = function () {

4:

5:var render = function () {

6:"use strict";

7:// We are using document.URL.split("?")[1] to pass the original query string parameters

8:// to all other pages. Note that this is currently possible only when using JavaScript

9:// to render Chrome control, the declarative rendering has a bug which prevents the

So pretty much just copy-paste from the MSDN article above. The important part is the SPWorkshop.ChromeControl.render() method. Here we first define the options for the Chrome Control (lines 11-29) and then load it in the line 31. In the options I specified several other pages that should be linked up in the Chrome Control (Contacts.aspx, Welcome.aspx, Help.aspx) and I want to pass the original URL query string to all those pages so that they can access all the SharePoint context info passed in the URL. I did it like this:

"linkUrl": "../Pages/Contacts.aspx?" + document.URL.split("?")[1]

And this works fine, when I load the page, my Chrome Control is loaded and when I click on the “Settings” wheel in the top right corner I can see the link to the Contacts.aspx page in the status bar containing the query string with the SharePoint context info:

When I click on the Contacts link, I am redirected to the Contacts.aspx page and the entire query string is copied over, so my URL looks something like

See that pulp after Contacts.aspx? That’s the context info that SharePoint passed to my Default.aspx and that I now passed on to the Contacts.aspx thanks to that “…document.URL.split("?")[1]” line in the Chrome Control options. So far, so good.

Now on to the problem. The alternative way to load the Chrome Control in your page is declaratively through your aspx markup, something like this:

...

<body>

<formid="form1"runat="server">

<divid="chrome_ctrl_container"

data-ms-control="SP.UI.Controls.Navigation"

data-ms-options=

'{

"appIconUrl": "../Images/AppIcon.png",

"appTitle": "SharePoint 2013 App",

"appHelpPageUrl": "../Pages/Help.aspx?" + document.URL.split("?")[1],

"settingsLinks": [

{

"linkUrl": "../Pages/Contacts.aspx" + document.URL.split("?")[1],

"displayName": "Contacts"

},

{

"linkUrl": "../Pages/Welcome.aspx" + document.URL.split("?")[1],

"displayName": "Welcome"

}

]

}'>

</div>

<div>

<h1class="ms-accentText">Hello World</h1>

</div>

</form>

</body>

...

See those “data-ms-control” and the “data-ms-options” attributes? The JavaScript code in the SP.UI.Controls.js recognizes them and renders the Chrome Control in the parent HTML element (here the “chrome_ctrl_container” div).

Now all you need to actually render the control at runtime is this piece of JavaScript in your document load handler:

However, when you deploy your app and browse to the page, instead of the Chrome Control you will be greeted by the nasty “Invalid JSON data".” JavaScript exception and a blank screen:

After some digging in the SP.UI.Controls.js I found the root cause. When declaring the Chrome Control declaratively in the aspx markup, the SP.UI.Controls.js checks if the Chrome options passed in the data-ms-options attribute are a valid JSON string according to the JSON standard from http://json.org, and in this case this is NOT a valid JSON thanks to those “ + document.URL.split("?")[1]” calls that are supposed to pass the original query string to other pages. However, in this case this string passed in the data-ms-options attribute doesn’t have to be a valid JSON string, since it is later executed using the JavaScript eval() function, so it should only be a valid JavaScript code which it is. So we have a bug here.

To prove that this is correct, remove the “+ document.URL.split("?")[1]” from the markup and redeploy your app again, this time the Chrome should load fine, except that your links to the Contacts.aspx and other pages now no longer get all the nice info from the URL query string (again, pay attention to the URL in the status bar, now without the query string):

<body>

<formid="form1"runat="server">

<divid="chrome_ctrl_container"

data-ms-control="SP.UI.Controls.Navigation"

data-ms-options=

'{

"appIconUrl": "../Images/AppIcon.png",

"appTitle": "SharePoint 2013 App",

"appHelpPageUrl": "../Pages/Help.aspx?",

"settingsLinks": [

{

"linkUrl": "../Pages/Contacts.aspx",

"displayName": "Contacts"

},

{

"linkUrl": "../Pages/Welcome.aspx",

"displayName": "Welcome"

}

]

}'>

</div>

<div>

<h1class="ms-accentText">Hello World</h1>

</div>

</form>

</body>

So how do you pass the query string to the pages called from the Chrome Control when it is declared declaratively in the aspx markup? You don’t, there is no way to circumvent this bug unless you change the SP.UI.Control.js which is not supported. In other words, you will have to use the JavaScript way to load the Chrome Control until this is fixed.

Note: examples similar to this one with attempts to pass the query string to the pages in a declarative Chrome Control were used in highly popular and otherwise highly recommended books “Inside Microsoft SharePoint 2013” and “Microsoft SharePoint 2013 App Development” and they won’t work either due to the same problem – so don’t waste your time looking for the solution, there is none at this moment (SP 2013 with April 2013 CU).