Strange. If you open the Tools->Options->Debugging dialog in Visual Studio, is the "Require source files to exactly match the original version" item checked? If it is not checked, that may cause it to use an old source file in the debugger. As far as I know, the PDB age is part of the symbol file's unique identifier - when Visual Studio asks for symbols, it makes a request to a URL with the PDB GUID and age. I think age normally gets incremented when a project is rebuilt in Visual Studio, though I don't know the rules about this for sure. Since you get the correct symbols/source if you clear out the symbol directory, I'm guessing Visual Studio just isn't making a request to ProGet because it thinks it already has the correct files. The best thing to do in this case is to run Fiddler and capture a trace of both behaviors and see what's different. You can send us a copy of these to support at inedo.com if you want some help troubleshooting.

This error is coming from nuget.exe; depending on the version of nuget.exe you're using, AD / integrated authentication simply will not work. It's supposedly fixed in 2.8.2, but some users say it doesn't work in 2.8.3. It's pretty broken in 2.8.1 and 2.8.0. Although it sometimes works in 2.7. The 2.6's seem to be fine, for the most part. ProGet.exe, from the now-defunct client tools, of course will work fine, or a simple HTTP PUT operation.

This question is answered here: http://stackoverflow.com/questions/26592119/buildmaster-net-framework

This question was resolved via other means, but the solution would be to upgrade to v4.5+ of the Azure extension.

Good questions, take a look at the Upgrade Notes for each minor version from 4.0 to 4.4, this will detail any breaking changes, but those are generally related to SDK and API use. If you have not developed your own personal custom extension, then you can ignore the SDK breaking changes. To make a backup of all BuildMaster settings, simply backup the BuildMaster SQL Server database. The installer should give you the option to do that as well provided the software is installed on the same server that hosts the database.

I'm not sure the component we use to FTP supports negated wildcards, but you can simply add a Delete Files action before this that operates on *.config Alternatively (if you don't want to delete because you may re-use the files), you can use the Synchronize/Transfer Files action to a temporary directory (e.g. ~\Ftp) and use a !*.config mask on that to not transfer the configs, then use the FTP action from ~\Ftp as the source directory.

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.

Hi, Thanks for the bug report; this will be addressed in the next release of ProGet, which is due in just a few days!

When iam using USB to unlock build master showing error server is not started How can I solve this problem

You can pull the artifact out of _PublishedWebsites, or try the "This is a Web Application" checkbox. There is a transform config file action available as well, though you can store your configuration files in buildmaster.

[3] – yes; I'm currently doing the following: Create an application package (by using the standard "Package" target in my "Build .NET MSBuild Project" action) Create a BuildMaster build artifact (i.e. create an archive file containing the application package and ancillary files) Deploy the build artifact to a folder on the build server. Run Web Deploy (msdeploy.exe) via a "Execute Command Line" action to deploy the application package (in the folder to which the artifact was deployed in [3]) to the relevant server(s) for the environment.

Yes,I would think the same. Thanks for clarifying. Please plan to release this fix at the earliest possible and would be glad if you can keep us informed on the same. For now, building .NET projects is really turning out to be a painful task just because of this one issue. Fortunately, there are some tedious workarounds.

I think the problem may have to do with your project/solution configuration (i.e. .sln and .vbproj/.csproj files). In the action's execution log, you can see the exact command run by the Action. I would suggest to run that command at your desktop, and then try to see what specific project is missing the output path... and then tweak the project files.

FYI we have released a new version of the DotNetRecipes extension, if you update that extension within BuildMaster then re-create the example app, the signing should work correctly. As for the certificate hash problem, that has been resolved in the .NET extension which is scheduled for a release later today or early tomorrow.

We have a known issue where if you have two test actions with the same group name in the same deployment plan, you will get this error. The workaround is to use a different group name for each test action in the same plan.

I was refering to Strong-Naming. I was using a passworded file .pfx and therefore causing issues, I moved to a .snk file (not password protected) and it's working correctly now.