Installing/enabling external tool in Administrator install of Skyline

Installing/enabling external tool in Administrator install of Skyline m j noga  2021-01-14

Dear Skyline Team,
We are using Skyline in a very restrictive environment where Administrator install is the only way to make it run for regular users. I am currently exploring the possibility to also use external tools to better integrate it in our workflows. I see I can install and run a tool with the Administrator account but this tool is not showing up in the Tools menu for regular users.
Is there any way to make Skyline discover tools installed by admin?
I see I can enable the tool manually by filling in the form through Tools->External Tools...->Add...->Custom and changing the command path for absolute path to the executable in Tools folder within Skyline installation directory. So while it allows me to achieve the goal, this is a rather complex workaround considering what my users need (it also requires manual installation of report and annotations). I wonder if there is a simpler way.
I see there was also a similar call in 2018: and I wonder what changed since then as Nicks suggestion was not very encouraging.
I will very much appreciate your help!

Nick Shulman responded:  2021-01-14
I still do not know how you would go about getting external tools to work across users for the Skyline Administrator Installer.

Are you sure that your users can't use one of the regular installers?
There is the Unplugged Installer:
This one involves downloading a .zip file and running the "setup.exe" which is in there.

Also, if your users are unable to run the setup.exe that is in there, I believe you can copy the contents of of that .zip file into their home directory, and they can run the Skyline.exe that is in there.

I am not sure exactly what you miss out on if you run Skyline.exe directly from the unplugged installer extracted folder. (Someone else might know whether anything bad might happen if you do this).

If you are willing to wait a few months, we might be able to figure out how to fix it so that the next version of Skyline allows external tools to work across users.
-- Nick
m j noga responded:  2021-01-20
Dear Nick,

Many thanks for your quick response!

Sadly, the environment we are working is too restrictive to allow using other installations of Skyline. In nutshell, regular users are not allowed to execute any program that is not provided by IT or installed and whitelisted in a specific way. In practice this means we can only install to Program Files, so Administrator install of Skyline is the only way to get it running here. The same execution restrictions apply to any external tool we would like to use with Skyline so these cannot be installed by user (as in: placing the executable in Program Files and whitelisting it).

Following your response I was investigating a bit further what are the actual constrains of our system exactly and how to interface it Skyline better. Fortunately, we can configure the tool manually through "Tools->External Tools...->Add...->Custom", providing absolute path in 'Command' field.

However, every user needs to type it in manually. We can work with that, but it would certainly help if there was a way in which Administrator could add tools configuration for regular users, either by a central configuration file or by auto-discovery by skyline (for example scanning tool folder on startup for tool-inf properties files).

Other way that would help is to use tool installation through .zip file that just reads tools-inf properfies files to read and save settings in a way that it can work when tools directory is read-only for user. This way users could at least fill the settings automatically.

Thanks for your efferts, Skyline is a very useful tool for us!

Nick Shulman responded:  2021-01-20

You can control the settings which users get by default by editing the file:
C:\Program Files\Skyline\Skyline.exe.config

I am attaching a .config file which I made on my computer which adds some "Shared MSstats" menu items to the Tools menu.
I inserted something that looks like this:
<setting name="ToolList" serializeAs="Xml">

inside of the element that says:

What I would recommend that you do is run Skyline.exe as an administrator and add the external tools to Skyline.
Then, search on your computer for the most recent copy of "user.config", somewhere inside of C:\Users\<username>\AppData\...
Open that text file, and find the "ToolList" element, and copy the entire <setting> element that contains it.

Paste that element into the right spot in "C:\Program Files\Skyline\Skyline.exe.config" and save it.

Then, whenever a new user runs Skyline, they will see these tool items.

I do not have very much experience with editing "Skyline.exe.config", but I know that it exists so that systems administrators can control the default settings that users get when running Microsoft .Net applications.

Let me know if you run into any problems. It might be that getting the menu items to show up on the users' Tool menus turns out to be the easy part, and something might go wrong when they try to actually use the tool, but I do not foresee any specific problems.
-- Nick
m j noga responded:  2021-01-26
Dear Nick,
Many thanks, this is very useful! It looks like a proper way for us to deliver pre-configured Skyline for users. I see there are more settings that we could use, like pre-configuring spectral libraries.
I was just doing some quick tests:
- it appears to work almost as expected for Administrator user, however I had to delete user configuration file to see the entry added in Skyline.exe.config in the tools menu. Is this expected? Is the user setting always overruling the global setting or is it possible to have the system merge both configs?
- for regular users, Skyline fails to start after editing Skyline.exe.config and removing user.config in C:\Users\<username>\AppData\... Do you have any suggestion how to troubleshoot that? Is there any log file Skyline makes? Could this be access right issue?

Best regards,

Nick Shulman responded:  2021-01-26
Yes it makes sense that the user.config would override the settings in the Skyline.exe.config.
This overriding happens at the individual setting level. So, if the "user.config" has no entry in it for "ToolList", Windows will use the value that is in Skyline.exe.config.
When the user exits Skyline, Skyline only writes the properties to the user.config that the user actually changed. If you had to delete a user's settings file, I think that means that that particular user did at some point use the "Tools > External Tools" menu item in Skyline to add a tool or something.

There is a "Clear All Saved Settings" button in Skyline at:
Tools > Options > Miscellaneous
I believe that pushing that button is effectively the same as deleting the user.config file.

If you are seeing that Skyline fails to start after editing Skyline.exe.config and deleting user.config, then it sounds like there is a setting in Skyline.exe.config which prevents Skyline from starting, and there was an overriding entry in user.config that was protecting that user from using that setting value.
If you send me your Skyline.exe.config (and the deleted user.config if you still have it) I might be able to guess what the issue is.
Failing that, the usual way to troubleshoot this would be to restore some of the different parts of Skyline.exe.config back to what they were when they were working and see which change is causing the behavior you are seeing.

You can certainly try debugging Skyline yourself using Microsoft Visual Studio. You can find the source code for Skyline 20.2 here:
or you can download a .zip file containing the source code here:

Please do send me your Skyline.exe.config. I will see if I can figure out what is going wrong.
-- Nick
m j noga responded:  2021-01-26
Dear Nick,

Thanks again! It turned out the failed startup of Skyline was likely caused Windows glitch, maybe related to possible multiple instances of Skyline running in alternating remote desktop sessions. It is all working now as expected, but I very much appreciate your patience and very kind offer of help!

Thanks for the hint about reseting settings from the app, definitely useful!

Could you clarify a bit how user.config and Skyline.exe.config work together? I see that global setting for a property will be ignored if it also exists in the user.config. What will happen if now user adds another tool manually? Will Skyline copy the settings for all tools to user.config? Will any changes in Skyline.exe.config be visible to user that changed settings of the tool? What would be the best strategy to keep some settings updatable by admin but still allowing users to add/modify things if they need so?

Looking some config files I have I see I can use "PersistedViews" setting to install report for the tool. However, I noticed this removes all standard reports and views. When I look at user.config at a development workstation I see not all reports are saved as "PersistedViews" settings. Are there also other setting files I should keep track of? I can imagine I could find it all in the source code, but I would appreciate some pointers to get started.

Nick Shulman responded:  2021-01-26

If a user adds a tool manually, their user.config will contain the list of tools which contains a copy of the items that were in the list in Skyline.exe.config when they started Skyline as well as the new tool that they added.
They will not be able to install tools from zip files or the Tool Store, because when Skyline installs a tool Skyline always wants to copy it into a subfolder of where Skyline.exe is, which these users probably do not have write permissions to.
Other users will not see these items that the user adds. They will only be saved in that user's user.config file.

I am not sure I understand what sort of things users could add manually, since they cannot actually install new tools.

All of a user's reports are saved in that one "PersistedViews" setting. They should all be there, including the reports that you get when you install Skyline (e.g. "Transition Results"), reports that they created themselves, and reports that came with external tools (e.g. "MSstats Input").
The PersistedViews setting is divided into "Main" and "External Tools" sections.
I would expect that you would see all of the reports in that user.config file. Are you sure that you are looking at the current user.config file? Windows saves around a few of the last versions of Skyline.exe that have been installed in case you want to use Control Panel to roll back to an earlier version of the software.
Yes, it does sound like it will be a bit of a pain that you need to tell users to reset their settings when you install new tools so that they will be able to see the new external tools reports. Maybe in a future version of Skyline we could make it so that external tools reports get saved in a different setting than the reports that the user designs themselves.
Users can back-up their report definitions in a ".skyr" file before they reset their settings by going to:
File > Export > Report > Edit List > Share

-- Nick
m j noga responded:  2021-04-20
Dear Nick,

Many thanks again for your help with this problem!
In the meanwhile I was investigating different options to achieve scriptable installation of external tools in administrative install and noticed that almost all can be achieved through command line interface through '--report-add' and '--tool-add' options.
(Seemingly) the only bottleneck I see is that adding a report through '--report-add' always adds the report to the <views name="main"> while '--tool-add' expects to find it in <views name="external_tools">.
Do you maybe know if it is possible use command line interface to achieve any of the following:
- use '--report-add' to add a report to "external_tools" group
- use '--tool-add' with ''--tool-report' to use a report from the main group
- copy a report previously installed by '--report-add' to "external_tools" group
I believe any of these option would allow me to deliver tools for our users without resorting to hacking skyline configuration files (either user.config or Skyline.exe.config).
I will appreciate any help you could provide!

Brendan MacLean responded:  2021-04-20
Hi Marek,
I would recommend that you instead use --tool-add-zip and review the documentation for external tools here ("Installable tools" section):

Then you can also go to the tool store page on the website and download some of the tools there and look inside their ZIP files for how they structure the tool-inf folder.

Using these options should give you the full range of options for installing a tool.

One thing I am unsure of with the administrative installer is that you would usually run the command-line interface with SkylineCmd.exe, e.g.

C:\Program Files\Skyline\SkylineCmd.exe

And I think this EXE may not share a user.config with the Skyline.exe, which means that changes like this will not impact Skyline.exe. However, when users with the web installation of Skyline run SkylineRunner.exe, they are actually running Skyline.exe underneath and then settings changes are stored in the Skyline.exe user.cofig file.

I don't think we have yet fully solved the settings issue with SkylineCmd versus Skyline. Sorry this is not as well solved as we would like it to be.

m j noga responded:  2021-04-20
Dear Brendan,

Many thanks for your lightning-fast response! I think you are doing really good job with Skyline even if here are there are some rough edges.

I am familiar with the installation process using .zip files and I do have a functional version of my tool packaged this way. This is very handy and nicely-designed functionality that allows me to test the whole process on my development machine. Unfortunately, as I explained to Nick in posts above our production environment is very restrictive and installation through zip file will not work, as 1) C:\Program Files\Skyline\Tools is read-only, 2) execution policy only allows whitelisting executables in direct subfolder of C:\Program Files\ which excludes possibility to use default tool directory anyway.

My current installation process involves 1) manual set up and whitelisting of tool executable by an admin and 2) manual installation of reports and tools by every user. I am now seeking to automate 2):
a) I can install report through command line by invoking - C:\Program Files\Skyline\Skyline.exe --report-add=my_report.skyr (this actually works and correctly updates user.config for Skyline.exe, indeed running C:\Program Files\Skyline\SkylineCmd.exe has no influence on Skyline GUI)
b) running C:\Program Files\Skyline\Skyline.exe --tool-add=... --... fails because Skyline cannot find the report
c) when I launch GUI I see the report installed I can manually copy report to external tools group
d) now running C:\Program Files\Skyline\Skyline.exe --tool-add=... --... exactly as in b) works correctly
I'm now wondering if there is a workaround for c).

One thing that now pops up in my mind that I didn't try yet: it is possible to have a that contains only tool-inf directory and a .skyr file constructed only for the purpose of installing the report? For example this would be something similar to pre-installed SRM collider using URL to bypass the executable check. Would it install through --tool-add-zip with read-only Skyline directory?