Sitecore: TDS Global Config issue with VSO Build Definitions

This is an issue I encountered with Sitecore, TDS and VSO. Everything would compile just fine locally, but when I setup a Build Definition in VSO I would get the following error for all of my projects...

"d:\a\1\s\src\Feature\Category\tds\TLG.Feature.Category.Master\TLG.Feature.Category.Master.scproj" (default target) (25) ->
  d:\a\1\s\TdsGlobal.config(2,1): error MSB4025: The project file could not be loaded. '.', hexadecimal value 0x00, is an invalid character. Line 2, position 1. [d:\a\1\s\src\Feature\Category\tds\TLG.Feature.Category.Master\TLG.Feature.Category.Master.scproj]
"d:\a\1\s\TLG.sln" (default target) (1) ->
"d:\a\1\s\src\Feature\Ceros\tds\TLG.Feature.Ceros.Master\TLG.Feature.Ceros.Master.scproj" (default target) (26) ->
  d:\a\1\s\TdsGlobal.config(2,1): error MSB4025: The project file could not be loaded. '.', hexadecimal value 0x00, is an invalid character. Line 2, position 1. [d:\a\1\s\src\Feature\Ceros\tds\TLG.Feature.Ceros.Master\TLG.Feature.Ceros.Master.scproj]
"d:\a\1\s\TLG.sln" (default target) (1) ->

What I ended up doing was removing the following from the top of the generated TDSGlobal.config...

<?xml version="1.0" encoding="utf-8"?>

After that, VSO compiles everything just fine. As far as I can tell the TDSGlobal.config is still working. I'm not sure of any possible negative repercussions from removing this line, but so far I haven't seen any and it got around the error.

Sitecore: TDS bundling error

Another random TDS error I've encountered a few times now. It seems to stem from renaming and/or moving around TDS projects too much. I'm not 100% on the exact cause, but the error that gets generated...

Which isn't very useful. Looking at a more Detailed output...

"Bundling files from project 'xxx.TDS.Master.scproj' into pacakge...
Exception Value cannot be null."

If you attempt to build only the TDS project listed, then it compiles without any errors. If you attempt to build a different TDS project that uses the Multi-project Properties tab to do Package Bundling, then you get the shown error.

The fix (for me at least) was to change the value of the "Recursive Deploy Action" dropdown, then save and rebuild. You can immediately change it back to the original value, but you need to force it to re-save its value to the .scproj file.

Repeat for any affected TDS projects, and your bundling functionality should work again.

TDS Error - VerifyTDSVersion task failed unexpectedly

I've received this error several times now, and it feels like each time it stems from a different issue, so I'm going to update this post every time I receive this error to track the different possible solutions.

1. Restart Visual Studio
This error often happens when adding a new TDS Project to an existing solution, and then immediately trying to compile. In this case, I just restarted Visual Studio and the new TDS Project compiled without errors.

2. TDS Version Mismatch
We use the HedgehogDevelopment.TDS.x.x.x.x.nupkg NuGet package to allow our VSO to compile TDS projects without having to install anything on the VSO server. With multiple developers working on a project, not all are always sync'd on the same version of TDS. Having a lower version of TDS installed on your local Visual Studio than the NuGet package version being used has caused this error before.

Issue: Octopus Deploy, Sitecore CD server receiving an older build

I have a project that is setup for CI/CD using VSO and Octopus. VSO has a build definition that compiles the code twice, once under a Release-CM configuration and once under a Release-CD configuration (to take advantage of transforms). Both generate a TDS Update package to be pushed to my Sitecore servers.

I was running into an issue where Octopus was installing the most recent CM Update package, but was sometimes installing the previous build's CD package.

It turns out the problem stemmed from how VSO was interacting with the Trigger in Octopus that was generating the new Release. VSO would build the Release-CM first, which would generate the CM Update package and send it to Octopus, then build the Release-CD second, and send the CD Update package to Octopus. Octopus was triggering a Release when it got the CM Update package, and sometimes the CD Update package was making it in time to be included in the Release, and other times it wasn't so Octopus was just using the most recent version it had (the previous build's version).

The solution was to switch the Trigger to wait for the CD Update package before generating the Release. Easy!

Solr Cores for Sitecore for Solr 6.2.1-0

Here are the necessary empty solr cores for a Sitecore 8.2 update 2 install, running on Solr 6.2.1-0. This includes "xxx_secondary" cores for using Switch On Rebuild functionality.

Deploying Sitecore's Session Database to Azure

If you're using Sitecore 8.2 and up, you have the option of using Azure SQL. It's pretty easy to push all of the Sitecore DBs up to Azure, except for the Sessions DB. You need to run a quick SQL script to edit the database's schema before you can push it to Azure, otherwise you'll get errors.

From Oleg Burov's GitHub...

USE [Sitecore_session] GO /****** Object: StoredProcedure [dbo].[CreateTables] ******/ IF OBJECT_ID('CreateTables') IS NOT NULL DROP PROCEDURE [dbo].[CreateTables] GO

If you need more details about how to get your Sitecore DBs out to Azure, Oleg has a nice guide on deploying to Azure.

Solr Cloud Patch for Sitecore 8.1

Sitecore has some issues working with Solr Cloud out of the box. There is an unofficial patch for it here. I was able to get it to work with my setup (8.1 rev 160302, Solr Cloud 5.3.1, Castle.Windsor 3.3), with the following modifications.

1. No changes to the Global.asax file. Use the default one.
2. Disable the file Sitecore.ContentSearch.SolrProvider.CastleWindsorIntegration.dll in the \bin folder.
3. Add the file Sitecore.Support.405677.Windsor.dll to the \bin folder.
4. Add the file Sitecore.Support.ContentSearch.Solr.WindsorInitializer.405677.config to the \Include\Sitecore.Support.405677 folder.
5. Add the file Sitecore.Support.449298.dll to the \bin folder.
6. Add the file Sitecore.Support.449298.config to the \Include\Sitecore.Support.449298 folder.
7. Add the file Sitecore.Support.449298.SwitchOnRebuild.IndexConfig.example to the \Include\Sitecore.Support.449298 folder.
8. Enable and configure the file Sitecore.Support.449298.SwitchOnRebuild.IndexConfig.example. This includes setting the collection names for the master, web and core indexes, as well as the ServiceBaseAddress of your Solr instance.
9. Add the file SolrCloud.config to your \zzzMustBeLast folder (or whatever your equivalent "run these configs last" folder is).

The SolrCloud.config file switches ALL the Sitecore indexes over to using the patched Solr Cloud indexing. Feel free to edit this as needed, or to include your own custom indexes in here.

Note: Make sure that your Solr instance has all the cores that you've declared in these indexes. IE: sitecore_master_index, sitecore_master_index_secondary, etc.

WARNING: When using this patch, you will notice some ERRORS appearing in your log that coincide with whenever you open the Index Manager window. I have confirmed with Sitecore Support that this is just noise and can be ignored, it doesn't affect the functionality of the patch.

"You can safely ignore these messages. They indeed happen to Indexing manager and bound to the fact that we can't get index summary in the current realization of this patch. But this shouldn't affect indexing and everything should work fine."

Here are copies of all the files I used.
Sitecore.Support.405677.zip
Sitecore.Support.449298-8.1.zip
SolrCloud.config