We do intend to upgrade the SDK used to get the newer version working, but there is no specific schedule for when this will happen at this point. If this is a showstopper for your team please email us at support@inedo.com

I'll try changing the type to IIS-hosted and see what comes of it. Just seems a little strange, since we've been running with the same configuration (TCP-hosted) since BM 4.0.5, without any issues. At some point (I believe within the last month), all build agents began failing at random times. Whatever version it was, around the same time we were no longer able to use SSL on the agents and we haven't tried using it since.

The exact process is detailed on the page used to switch over, but here are some troubleshooting ideas: ensure both Windows Auth & Forms Auth enabled for the website ensure Anonymous Authentication is disabled ensure there are administrator privileges granted before switching perform an iisreset on the web server if using IIS

I believe someone from our support staff emailed you a quick fix for this. It appears the double.Parse() method was not taking the current NumberFormatInfo into account for some reason.

Thanks for the report! Just update the site to fix this.

Yes, and we have actually already implemented it for our next release :) We're thinking of releasing a beta version of 3.0 today if you want to be on the lookout for it.

It's alphabetical. We've considered adding in a sequence, but have found that most folks will prefer the old "GWBasic" route of prepending an integer to the name to determine execution order. First SCript Second Script Last script This ordering comes after the release ordering.

Yes, all good. That directory is monitored for changes, and when a change occurs, the contents are re-indexed.

I just restarted the service and now it's showing the new version...

Hey Tod, Totally odd - but this is how I fixed it. I added a few extra files into the web project, clicked an "included in project" Due to this the .cproj file was changes (due to new files) Commited all changes in SVN waited 1 min, then started the build bam! finally it succeeded. May have been some sort of "stale" proj file or something.

Tod's answer gave me something to look for. The IIS 7.5 did not have ISAPI enabled so after doing that the proget site worked as a charm. Definitely something that is missing in the documentation! For further reference see below: To enable ISAPI in the IIS look here: http://www.iis.net/configreference/system.webserver/security/isapicgirestriction at the part Setup The <isapiCgiRestriction> collection is available only after you install the CGI or ISAPI Extensions modules on your IIS 7 server. You cannot install it independent of those features. WINDOWS SERVER 2008 OR WINDOWS SERVER 2008 R2 On the taskbar, click Start, point to Administrative Tools, and then click Server Manager. In the Server Manager hierarchy pane, expand Roles, and then click Web Server (IIS). In the Web Server (IIS) pane, scroll to the Role Services section, and then click Add Role Services. On the Select Role Services page of the Add Role Services Wizard, select CGI or ISAPI Extensions. If the Add role services dialog appears, click Add Required Role Services. (This page appears only if you have not already installed any prerequisite role services on your server.) On the Select Role Services page, click Next. On the Confirm Installation Selections page, click Install. On the Results page, click Close. After doing that i restarted and did not have to any further setup. Loading the site just worked. Inedo should make it much clearer in the documentation that this must be installed in the IIS for proget to work. Just setting the App Pool to Classic is not enough. Thomas

Thanks for the reply Tod. But I figured out the issue! We had earlier setup local repos on the BuildMaster server since the old Mercurial extension needed a local repo to be configured on the server. But the new extension for Mercurial does not have this constraint. So I just had to reconfigure the remote repos and everything is fine now.

Don't call the SOAP methods directly; that's not supported, and the communication protocols can change in maintenance versions since it's not part of the SDK. The best way to do this would be using the Util.Agents::CreateAgentFromId method. This will return an AgentBase instance. Once you have that, you can invoke the GetService<T>() method (with IRemoteMethodExecuter as T), and then run code on the agent with the IRemoteMethodExecuter::InvokeMethod) method to get any information about the agent you'd like. There is also AgentBase::GetAgentStatus) method, but that's not as easy to interact with since you need to construct a context to determine if the agent is considered outdated.

The linked action groups are more about "code reuse" than anything else. But you may want to check out the Promote Build and Create Build actions; those come in handy when dealing with dependencies like this. Usually, you'll see a promotion of ESB trigger the MainApp.

We are planning to fix this in BuildMaster 4.2, but in the meantime you can edit it directly in SQL on the Plans or PlanActionGroups table (depending on if you're using shared/overridden plans). The format is a long, persisted XML string that hopefully shouldn't be too difficult to figure out.

This is addressed in Microsoft KB321363: When you start Microsoft SQL Server, SQL Server memory usage may continue to steadily increase and not decrease, even when activity on the server is low. Additionally, the Task Manager and the Performance Monitor may show that the physical memory that is available on the computer steadily decreases until the available memory is between 4 MB and 10 MB. This behavior alone does not indicate a memory leak. This behavior is typical and is an intended behavior of the SQL Server buffer pool. By default, SQL Server dynamically grows and shrinks the size of its buffer pool (cache), depending on the physical memory load that the operating system reports. As long as sufficient memory (between 4 MB and 10 MB) is available to prevent paging, the SQL Server buffer pool will continue to grow. As other processes on the same computer as SQL Server allocate memory, the SQL Server buffer manager will release memory as needed. SQL Server can free and obtain several megabytes of memory each second. This allows for SQL Server to quickly adjust to memory allocation changes. That article will give some further links on how to adjust memory, but in general it's best to leave it alone. I believe SQL Express 2005 is capped at ~1GB usage anyway.

Hi To recap for future reference. To push a package containing symbols and sourcecode the following has been tested and worked fine with nuget 2.8: Create nuget package using: nuget pack foo.csproj -Symbols Alternatively use: nuget pack foo.spec -Symbols The above command will create two nupkg. The one decorated with the word symbols does contain all libs as well as the sourcecode and PDB files. You cna check yourselfes by opening hte nupkg in something like winzip or 7zip, since the package is basically a zip file. Push the symbols package to proget. check the package on the feed. If the symbols server is activated the package info will show that symbols and source are available. Follow the Inedo guide on how to add The Proget symbol server support into Visual Studio. Food for thought. My, very quick test, shows me that a package build in the .NET 4.0 framework, of course works fine in a .NET 4.5 project, but i could not use the symbols to debug. I tried to remove the package, downgrade my test project to .NET 4.0 and reinstall the package. Now i could debug nicely into the source. Bottomline. The symbols package and the project that uses it must be on the same .NET version for the symbols to work. Symbols compatibility does, apparently, not span framework versions, even thou the frameworks themselves are backwards compatible. Thomas

Sure, feel free to post that to GitHub. What types of projects are these? Typically you don't need to worry about dependencies if you get the source for the whole solution and just build the .csproj as MSBuild will handle that for you in the same way as if you built it in Visual Studio.

Can you send a screenshot to support@inedo.com exhibiting this behavior? In a quick smoke test my debug logs disappear when I remove the task from all the roles.

Alana, thanks for the suggestion. I will look at adding this, but do you have any ideas how I can get the execution id for the current execution? There don't seem to be any variables for it. I thought of trying to get it from the BuildMaster API using an HTTP GET request, but I don't see a way to store that to a variable.