angular-cli gave me problems. It tries to retrieve dependent packages from https://registry.npmjs.org. ( https urls don't works on our dev pc's) At the moment I also configured the server with the feed as my proxy server, so at least that traffic passes over this server for all package handling. (I also have github and such) Tnx for any info you can provide Stijn

Thank you very much! The 'Imported Deployables" functionality worked like a charm :-) Regards, Francesc

i have 2015 team explored installed but not succeeded in same schenario.

Sorry on the slow reply; this is extremely difficult to debug, because it involves a very complex set-up and expertise in undocumented LDAP/AD/NETBIOS conventions, as you might imagine… The problem is that the underlying libraries are returning that useless “server not available” error when trying to lookup the NETBIOS doman name. Here is how that query is constructed. private string GetNetbiosDomainName(string dnsDomainName) { string netbiosDomainName = string.Empty; DirectoryEntry rootDSE = new DirectoryEntry(string.Format("LDAP://{0}/RootDSE", dnsDomainName)); string configurationNamingContext = rootDSE.Properties["configurationNamingContext"][0].ToString(); DirectoryEntry searchRoot = new DirectoryEntry("LDAP://cn=Partitions," + configurationNamingContext); DirectorySearcher searcher = new DirectorySearcher(searchRoot); searcher.SearchScope = SearchScope.OneLevel; searcher.PropertiesToLoad.Add("netbiosname"); searcher.Filter = string.Format("(&(objectcategory=Crossref)(dnsRoot={0})(netBIOSName=*))", dnsDomainName); SearchResult result = searcher.FindOne(); if (result != null) { netbiosDomainName = result.Properties["netbiosname"][0].ToString(); } return netbiosDomainName; } Basically, it’s trying to enumerate all partitions and try to locate the netbiosname property. This is important to do because sometimes a credential will be sent to ProGet in a NETBIOSNAME\username or username@NETBIOSNAME format. The failure could be happening in one of two places (where the Properties collection is accessed), but shouldn’t be happening in either. Any assistance in identifying this would be helpful. We could just ignore this error, and assume that that a failed NETBIOSNAME resolution means the domain name is always the same, but we'd prefer not to just ignore errors like this...

Thanks for your response, Alana. Can you elaborate a little bit on the API commands you would leverage in this instance? I had considered that before, but I'd be curious to know how you'd approach this.

Can you provide more information on how to reproduce this? Ideally, if you could attach Fiddler or similar to capture the specific query that is causing the error, that will help us repro.

Well be releasing BuildMaster 5.1 in just a bit (later today), which will have these operations.

It looks like you probably mean to use an assembly-qualified name instead of the .Name property on line 68: So it probably should be something like: writer.Write(resultType.FullName + "," + resultType.Assembly.GetName().Name); That would generally be the minimum information you'd need to get the type with Type.GetType. That said, as you've discovered, RemoteJob is a pretty low-level interface, meant to give complete control over any over-the-wire serialization. You may want to look at the RemoteEnsureOperation as a base class to use instead, which handles the RemoteJob details internally - you just add the [SlimSerializable] attribute to properties that you want to be serialized and it takes care of the rest. You also may find the SlimBinaryFormatter class useful - it is the class that RemoteEnsureOperation uses to perform its serialization. Hope this helps!

Thanks; logged as [OTTER-77] and we will fix in next maintenace release!

This seems to be unrelated; the problem before was that ProGet was not providing a 404 when a package was not found, but instead an empty result. Also, we cannot reproduce this error at all, so it's isolated to yours. As such, please Ask a New Question as not fill this one; and also make sure to provide a stack trace of the 500 error message; this can be found in Admin > Error Logs.

I've managed to implement this using the BuildMaster API. The combined workflow now looks something like: Saturday 9:00PM (Prior status): Release 1: Hotfix Workflow Release 2: Deployment Workflow - Pre-Staging Saturday 10:00PM (Latest Release Deployed): Release 1: Marked as Deployed Release 2: Deployment Workflow - Deployed Saturday 10:30PM (New Release Created): Release 2: Deployment Workflow - Promotion Release 3: Deployment Workflow (No Build) Saturday 11:00PM (Automatic Build Triggers): Release 2: Hotfix Workflow Release 3: Deployment Workflow - Pre-Staging One of the steps executed during the Pre-Staging workflow (initiated as soon as a build is created) is to call a script which uses the API to first reject any active builds from the previous release, and then update the release with the new workflow. API Steps: Get Builds for previous release with Builds_GetBuilds. Check for any builds with Current_ExecutionStatus_Name == "Executing", fail if there are. Reject all builds with BuildStatus_Name == "Active", using Builds_RejectBuild Update Release with Releases_CreateOrUpdateRelease, setting the desired Workflow_Id.

It is sent with UTF-8 encoding, and this is sent as an HTTP header as well.

Hi, OK, thanks. Just to let you know, this was from version 5.10 to 5.11. David

This is definitely something we intend to address as part of our v5 roadmap; there just hasn't been a huge customer demand for automating BuildMaster using the sort of "temporary API access key" approach that has grown popular in the more consumer-facing things like Twitter, GitHub, etc. We may add this if there' demand and similar adoption in other tools in the space, but in our experience, it's generally more complicated for administers to manage and set-up. So they just set up one "access key" and give it to everyone. It's particular challenging for us to solve in the same manner because of the way BuildMaster scopes privileges (by application and environment), and because the Native API can work cross-application/environment. So, if it's a requirement to give limited access to Developers, the current best approach is to wrap the native api with a permissions wrapper, and then check if that user is authorized based on the AD group they're in, etc., based on the action they want to perform.

Guess it depends on the project. I removed -IncludeReferencedProjects on another project we have and that did resolve the issue. Seems to be that if the SRCSRV: {path}\src{ProjectName}{file}.cs not indexed error message contains the project name after src\ then you need -IncludeReferencedProjects. Maybe?

It's hard to say where the issue lies, but I would suggest to attach ProGet to a proxy server like Fiddler, so you can watch the requests that are made to npm vs MyGet. Ideally, a request to ProGet or MyGet should look and behave the same as a request to npmjs.org. But npm is an undocumented protocol, and there are a lot of quirks, so oftentimes it doesn't.

With regards to my question above, I have found this blog article that has helped me: https://richardspowershellblog.wordpress.com/2015/01/04/creating-a-powershellget-repository/ It talks about Proget and using a Nuget feed type, but the same methodology applies using the Powershell feed type.

It's hard to say, there's also the possibility that it's a bug; please keep in mind the npm "protocol" is undocumented, and lot of odd quirks that vary from client version to version, so it's possible this particular package is constructed in a way that we didn't account for. In this situation, the best way to see what the problem is, use a tool like Fiddler or Wireshark, and see which specific query ProGet is responding differently to.

Most definitely! This is what the <b>Asynchronous option</b> on a General Block is designed for. In OtterScript, it just looks like... with async { ... operations to deploy code ... } with async { ... operations to deploy database ... } await;