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.

Yeah we can add those. I've filed this issue as BM-1396.

Not exactly - it's simply used instead of reading the connection string from the appSettings file. To move the database, just back up and restore it to your new server and change the connection strings in the web application's Web_appSettings.config file and the service's App_appSettings.config file. Whatever service account is running the application pool or running the BuildMaster web server service needs to be granted the BuildMasterUser_Role for the new database as well.

There is no way to tell from that error alone what the problem is. Some questions to help troubleshoot: is the other feed also a ProGet feed, or some other type of a feed? Can you actually browse to and get packages from that other feed? Can you connect to the NuGet.org feed from the feed that current has the broken connector?

You can add an ExtensionIconAttribute assembly attribute to your extension for a custom logo that accepts a URL to the image in its constructor. Note that this attribute requires the BuildMaster SDK v4.1 or later. If you want to embed your image directly, you can convert the URL to a base64 string and embed it using a tool like this one: http://webcodertools.com/imagetobase64converter

Hi Max, That sounds like a great idea. Unfortunately, there is no SC Provider that is associated with a particular build; that is, there'd be no way (aside from looking at logs) to know which ProviderIds were used in deployment plans executed over a build's lifecycle. You could capture this as a variable, however. If you haven't already, make sure to see how the SourceControlProviderActionBase actions work; you can find their code thru a decompiler (BuildMasterExtensions assembly), or just ask for it and we'll email you. Hope that helps, Alex

After further investigation and help from support I found the issue. I am using the NuGet package and publish Visual Studio extension to create my NuGet packages. This is really just some MSBuild targets and supporting files that get included in your project/solution. What it does is use NuGet.exe to push the NuGet package and the symbols package. After further investigation (and help from ProGet support) I found that my packages were getting overwritten by the symbol packages. The reason for this is that NuGet.exe strips the symbols from the name of the NuGet package when it pushes. ProGet therefore has no way of knowing this is symbols package and since I have overwrite of packages enabled for the user that pushes the symbols package overwrote the primary package. The symbol package for obvious reasons only has the dll, pdb, and source files hence it looked like the content files were stripped. Since I didn't want to revamp my entire build process (it was already setup for about 30 projects across a number of solutions) I came up with an alternative approach. Since ProGet retains the symbols and source in the NuGet packages (it only strips them when they are downloaded) I created a separate feed for symbols and source (I named it SymbolsSource). This ends up working out beautifully. I push NuGet packages to Default and symbols to SymbolsSource and setup Visual Studio accordingly. I would like to give kudos to support for helping me out on this!

Sorry - I did mean .org in my previous response :) Still however, I am not able to reproduce this behavior that sets the Remote Repository to something other than what was typed in unless I edit an existing repository and do not save the edited values. If you could detail the exact steps you did (e.g. 1. Click Create New Provider button, 2. Input values abc and xyz, 3. click Test Connection, etc.) that would help tremendously.

In this case, you should install ProGet to IIS (it's an option in the installer), and configure SSL from there.