Just to follow up, got some help from the inedo folks and we discovered that the server hosting the sql server database had its system clock slightly off which was causing the delay till the start of execution.

Thanks; we were able to reproduce this, and will revert it to old (correct) behavior in a maintenance release.

ProGet runs just fine in Hyper-V; you may want to try a reboot... that will often fix it. The problem is usually the WMI service acting up

Waiting might be best for me. <-not so good with object oriented languages. I think it would be a great additions to be able to access the many types of Variables. (application, release, build are the 3 types I use, not sure about the rest of your client base) I expect my end result would look like: $ReleaseVariable(${ReferancedApplicaitonID, ,${ReferancedReleaseNumber, FolderNumber) Wow that just got crazy. Think it can handle passing in functions to find a variable? I am not in a rush, I just want to reduce the risk of problems. And because 4.3 did a major change to the database my built-in-house reports would have to be redone, so I am being lazy with updates. Also this solution would be able to consolidate some of my shared plans that each call different variables, if I instead ask for a variable by passing in the environment like this: $Appvar(${AppID}, ${EnvName}Server) I can have the same task work on all my environments. Thanks, Dan

SQL patch received and applied, thanks. The Manual action step is now working again. The log file detail shows in the same window using IE but only show as [View Full Log] in Firefox (no new tab or window is opened)

Unfortunately, NuGet does not distinguish between symbol and normal packages when uploading; all that's sent from the client is the package name, id, and bytes. Thus, there's no way to have ProGet automatically merge. In this case, you'll need to combine both packages in one, then upload it. Alternatively, you can create a symbols-only feed and upload to that.

Hi Tod, Thanks heaps, that makes sense to me. Thanks for the quick reply. Regards, Daniel.

It looks like this method was removed as part of the 4.3 executor refactoring; but it will be replaced in a maintenance release (shipping this week). If absolutely needed sooner, you can query the [BuildExecution_ActionGroupActionVariableValues] table direct or via a stored proc.

For reference, this also happened on another user's machine, and the following entry was found in the event log around the same time: Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards. DETAIL - 3 user registry handles leaked from \Registry\User\S-1-5-21-1409082233-789336058-1343024091-27055: Process 2940 (\Device\HarddiskVolume3\BuildMasterAgent\Agent\_tmp\bmtcpagent.exe) has opened key \REGISTRY\USER\S-1-5-21-1409082233-789336058-1343024091-27055 Process 4388 (\Device\HarddiskVolume2\Windows\System32\conhost.exe) has opened key \REGISTRY\USER\S-1-5-21-1409082233-789336058-1343024091-27055\Control Panel\International Process 2940 (\Device\HarddiskVolume3\BuildMasterAgent\Agent\_tmp\bmtcpagent.exe) has opened key \REGISTRY\USER\S-1-5-21-1409082233-789336058-1343024091-27055\Control Panel\International

Thank-you for the quick reply... I had just upgraded Proget just a week ago or something, so I hadn't thought to look for another version. I downloaded and installed the latest version and indeed my issue seems to be resolved.

Sorry about that, I got a little confused with BuildMaster's configuration... there is no appSettings.config file for ProGet :-/ ProGet's website port is determined by arguments passed to the service. If you stop the ProGet service, run ProGet.Service.exe as administrator, and choose Uninstall, the service will be uninstalled. You can run it again and choose "Install" to add it back, then it will ask for the URL to reserve, and you can enter something like http://*:1000/ to reserve all hostnames on port 1000. Make sure to choose an identity that has access to the SQL Server database. If you chose Network Service as the account to use when you first installed, just leave that as the default option for the user account when prompted. If the service takes a while to start up (i.e. longer than 5 seconds), it probably means the user account assigned to run the service does not have access to the DB (it could take a minute or more to time out). Just reinstall the service in the same manner to host with a different user.

That's correct in that it's too early to read the file, which is why it results in the sharing violation (the file is opened for write by w3wp.exe without FileShare.Read). The new file in the directory triggers the FileWatcher (which doesn't find the file because it's not completely written yet). However, the NotifyChangeDirectory operation in the feed directory will trigger the FileWatcher again after the file is completely written and closed in which case it would get picked up by the indexer, and that would make the package appear in the feed. Is there a way to run the monitor again to cross-reference the times that the error appears in the ProGet error log with a violation within the Process Monitor log? I am thinking that these particular sharing violations are not related to the errors you're seeing.

That sounds great, thanks a lot!

Oh I see what you mean - I thought you meant that you were able to upload packages using the NuGet client... I was able to reproduce in that way. We'll have a fix for this in maintenance release v3.0.4 (logged as issue PG-210). Apologies for the confusion.

It sounds like this is a bit of a hack; when an application component is deployed to a production environment, it's status should be represented as "Deployed". You can purge releases if needed using the Releases_PurgeReleaseData API/Sproc method.

Currently this is supported through the API, but not via the triggered builds. We will add the ability to specify a build number for URL triggered builds in the final version of 4.3 due out end of next week. You can already specify variables for URL triggered builds by including them as part of the query string, e.g. http://buildmaster-server/trigger-build?id=1000&myVar1=value1&myVar2=value2

Yes, although you may get some file read errors if someone happens to be downloading the exact package that's being backed-up or copied. Many back-up processes/tools will do things like shadow copy and limited read handles to prevent this from happening.

Thanks so much! This has been logged as PG-208, and we plan to fix in the upcoming maintnence release (3.0.4)

The main strategy is to have one application per website, and then either: Pull the core 30 projects and build them as part of each website application, you can use shared/linked action groups for this to make it a little easier. -or- Build the web core files in their own application as you've started to do it seems, and store the build output as an artifact, then import that deployable in each of your website applications. This allows you to deploy the artifact with the core files in it before you build one of your web applications. We've named this option the "Core Version" pattern, and you can find a specific example of it here: http://inedo.com/specifics/buildmaster-extensions I will also note that deployment plans are getting a nice overhaul in the upcoming BuildMaster v4.3, it will be much simpler to share deployment plans across applications so managing plans for this scenario will be even easier.

Thanks for the report - we are able to repro and will fix it in the next maintenance release.