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;

Ah ha, ok got it! I've identified the bug, and we will fix this in [BM-2003], shipping ASAP!

Thanks; I've logged this as a bug (BM-1999), and we will fix it in the next maintenance release.

Hello; you can request a key from my.inedo.com, and then enter that in the installer. Once installed, there will be activation instructions (because the software can't auto-activate). No internet access is required to install or use BuildMaster.

BM-1997 - FIX: Transfer-Files operation can create files with \ characters on Linux Thanks very much. Works as expected :-)

The feedCleanup makes sure the files on disk and metadata files in sync. It'd be fine to run weekly or disable. There are no additional settings available, but we may add something to mitigate this in the future; it's extremely rare, and it's quite complex to handle properly.

We have identified and fixed the bug responsible for this, and will have it fixed in the next maintenance release (Otter 1.1.5). Thanks for the bug report!

I cheated and did it in SQL, been digging a little bit into your database anyways. DECLARE @DefaultRaftId INT SELECT TOP 1 @DefaultRaftId = Raft_Id FROM Rafts WHERE Raft_Name = 'Default' UPDATE [Servers] SET Raft_Id = @DefaultRaftId UPDATE [ServerRoles] SET Raft_Id = @DefaultRaftId

Thank you Alana, this makes sense. I was trying to use a NuGet feed type. This answers my question.