Here is an example path to a .pdb file, the same folder contains .dll: C:\Users\nsitnikov.dnx\packages\JA.AppCentral.Logging\0.1.7-Build1\lib\dnx451\JA.AppCentral.Logging.pdb Package folder also contains the source in C:\Users\nsitnikov.dnx\packages\JA.AppCentral.Logging\0.1.7-Build1\src folder

Thanks for the quick response. Yes, sooner would be great. I will start using the new feature as soon as you can release it, with or without documentation.

If I use this string it returns me: System.ArgumentException: 'server' is not a connection attribute valid. What should I use instead?

Check out KB#1039 - The Inedo Agent and Legacy BuildMaster Agents for more information on this.

That's generally the idea of the arguments: those are the required variables. template MyTemplate<$var1,$var2,$var3> { ... } It's generally a good practice to use these instead of external or configuration variables. But you can always use the $IsVariableDefined function as well. if !$IsVariableDefined(my_var_name) { error; }

ignore my previous post. I had modified a second action and had left the first one with spaces, the semi-colons worked fine. Thanks

Just a heads up, that we've updated the docs with our proposed specifications, always open to feedback! Formal Grammar Formal Specification Strings and Literals We don't have an ETA; the changes aren't really that difficult, but once we implement them we're stuck with them.

A FileSystemWatcher is used, so any changes to the directory will trigger an import.

Yes I do see it there. I think the message on the key generation page implies that the key should be visible immediately after generating the key and is perhaps misleading. Thanks for the info.

You are not going wrong :) Support for XSL as the template and data as the instance will be added in v5.3.4 as a separate template type so it doesn't break existing deployments. We'll release this within the next day or so.

That was it. The user had access, but not permission to change schema. I really think this should be catch and a nicer message displayed instead of the installer just crashing though.

Hi Junaid, This is a known issue with npm; basically it's sending a JSON document with two "dist" properties. For example... { "dist": "value1", ..., "dist": "value2" } The JSON Library we're using isn't too keen on that, and we already have a fixe (PG-603) planned/scheduled for the next release.

Well, the NuGet API version is totally unrelated; and regarding the v3 API, it's still not stable/public yet, but they are planning a stable/public API at some point in the future (no ETA). Regarding SemVer v2 support for NuGet packages/feeds, tut The NuGet team reports they may support it in v3.5 or v3.6; if/when that happens, we'll add support for it in ProGet's NuGet feed.

Nice read, I just passed this onto a friend who was doing some research on that. And he actually bought me lunch as I found it for him smile Thus let me rephrase that Thanks for lunch! bagkeecdckkdedbb

Hello; I believe the error is due to a bug in the LdapDirectory code, which is not properly escaping that group name that has a parenthesis in it. So, we will need to fix the bug; I've logged this as PG-602, and we can get it in the next maintence release (which is targeted for next week). Best, Steve

Ok, so I have now got something working. It seems it was failing because I had the smaller installer (without sql server). That does absolutely nothing when running the silent command. If that's meant to be the case, then maybe that should be documented somewhere. Thanks

Alana, thanks. Just getting into using the script and didn't realize I could create a var with no value like that. Thanks!

Is there anything listed on the Administration > Error Log page that relates to this? Errors listed there will have additional context (feed, connector, etc) If it doesn't appear there, I guess you could enable 1 at a time to see which one is the culprit.

I actually am at fault for not being thorough here; I jumped in without being diligent. I am not using Integrated, but using LDAP provider via forms in Buildmaster and it was this that was failing. My apologies! Our custom OAUTH API gateway validates against ADFS prior to providing tokens, think of it as a custom Oauth2 token provider to provide SSO with Windows Auth. The whys and hows can be discussed offline if you want, though there are a few sites which explain this and the reasonings. This custom OAUTH Api/gateway worked at the time of Buildmaster not working. Hence my confusion about why one was working and not the other. With that said, I will still continue to monitor. I will assume this was a "fluke" on the system side that is not worth troubleshooting.

Ah yes, that solved my problem. Thanks!