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.

Hmm, not sure, but it sounds like the problem is a corrupt install package? That's a error thrown from within MSI extraction. Maybe try downloading the file again.

We will add the descriptions at some point (we have them in BuildMaster). The HTML should probably be in a div, as it renders the value as a literal string. You can try it with something like: <div class="white-box padded-box"><h2>{Company} ProGet Repository</h2><p>Welcome to our collection of ProGet feeds.</p></div>

This sounds like it's related to package indexing. Please see this StackOverflow answer for troubleshooting steps: http://stackoverflow.com/questions/23812344/publishing-to-proget-and-i-cant-see-any-packages

There is a "purge artifacts trigger" that you can set-up that will delete artifacts from Rejected Builds, either immediately or once the release is deployed. We do have it on our roadmap to have artifact retention and clean-up policies as a more advanced feature.

NOTE : BuildMaster has Retention Policies which are strongly recommended, rather than manually purging data That being said, you can use the same strategy to delete from that table that you used for log entries: BuildMaster 4.2 and earlier: SELECT TOP 100 * FROM BuildExecution_PlanActionVariableValues --DELETE BuildExecution_PlanActionVariableValues WHERE BuildExecution_PlanAction_Id IN (SELECT BuildExecution_PlanAction_Id FROM BuildExecution_PlanActions BEPA INNER JOIN BuildExecutions BE ON BE.Execution_Id = BEPA.Execution_Id INNER JOIN Builds B ON BE.Application_Id = B.Application_Id AND BE.Release_Number = B.Release_Number AND BE.Build_Number = B.Build_Number WHERE B.BuildStatus_Name = 'Rejected') BuildMaster 4.3 through 4.9: SELECT TOP 100 * FROM BuildExecution_ActionGroupActionVariableValues --DELETE BuildExecution_ActionGroupActionVariableValues WHERE BuildExecution_ActionGroupAction_Id IN (SELECT BuildExecution_ActionGroupAction_Id FROM BuildExecution_ActionGroupActions BEAGA INNER JOIN BuildExecution_DeploymentPlans BDP ON BEAGA.BuildExecution_DeploymentPlan_Id = BDP.BuildExecution_DeploymentPlan_Id INNER JOIN BuildExecutions BE ON BE.Execution_Id = BDP.Execution_Id INNER JOIN Builds B ON BE.Application_Id = B.Application_Id AND BE.Release_Number = B.Release_Number AND BE.Build_Number = B.Build_Number WHERE B.BuildStatus_Name = 'Rejected')

Wow, what an incredibly fast response. Thanks

This sounds like it's related to package indexing. Please see this StackOverflow answer for troubleshooting steps: http://stackoverflow.com/questions/23812344/publishing-to-proget-and-i-cant-see-any-packages

To expand on this story what we are thinking about doing is creating a wide open pass through feed to Nuget that would allow users to discover new open source software to use. By forcing users through Proget we can get user info to send them reminder emails about OSS that we have not yet cleared for use in our products. Then the devs can get it cleared etc.

Are you overwriting an existing package when this happens, or are these fresh packages that are getting uploaded? Either way, if you could send that Process Monitor output to support@inedo and reference this post that would be very helpful, thank you!

We believe that it should not because it's most likely a mistake to specify a directory that doesn't exist as the working directory since presumably there could be files to work with, etc. in that directory. As you mentioned, the workaround is to create the directory before this step. I would just use mkdir in a PowerShell or Bash script.

At this point in time, it is unlikely. However, Atlassian does mention on their site that plugins could be created to integrate with third-party tools, and the JSON ProGet API could be used for this.