I have a SSIS project that I have created that has the DontSaveSensitive protection level and has happily deployed to the local server several times before today. I am now, however, getting the following error on deployment:

A .NET Framework error occurred during execution of user-defined routine or aggregate "encrypt_binarydata": System.IO.FileLoadException: Could not load file or assembly 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. Not enough storage is available to process this command. (Exception from HRESULT: 0x80070008) System.IO.FileLoadException: at Microsoft.SqlServer.IntegrationServices.Server.Security.CryptoGraphy.CreateSymmetricKey(String algorithm) at Microsoft.SqlServer.IntegrationServices.Server.Security.CryptoGraphy.EncryptBinaryData(SqlString algorithmName, SqlBytes key, SqlBytes IV, SqlBytes binaryData) . (Microsoft SQL Server, Error: 6522)

I have had a google but come across nothing that specifically references encrypt_binarydata. There are a number of references to deploy_project_internal or untrusted assemblies but nothing on this particular issue.

The important part seems to be

Not enough storage is available to process this command

but I can't make head or tail of this as there are many gigabytes of RAM going spare and plenty of drive space to use so the resources shouldn't be problem.

Can anyone shed any light on what this error is referring to and ideally how I can resolve it?

Turns out this is a problem with permissions that gets very muddied deep down in the inner working of the SSISDB, between SQL and dll files. The error message in the original question is actually a bit of a red herring and the real problem was the same as the one solved in this excellent resolution.

For posterity's sake in case that answer ever disappears (as well as for lazy people that don't want to click another link), here is the referenced answer in full

Credit to Remus Rusanu

Assemblies with EXTERNAL_ACCESS are, through some convoluted path, falling under the EXECUTE AS path. The problem appears when the 'dbo' cannot be mapped to a valid login. dbo's login is the login with the SID the owner_sid value in sys.databases. Unless an AUTHORIZATION clause was used in CREATE DATABASE the owner_sid is the login sid of the principal issuing the CREATE DATABASE statement. Most times this is the Windows SID of the user logged in and issuing the CREATE DATABASE. With this knowledge in hand one can easily envision the problems that may arise:

• copy database: CREATE DATABASE was issued on machine A by an user local to A (ie. MachineA\user or DomainA\user) then the database was copied to machine B (via backup/restore or via file copy). The owner_sid is preserved by file copy as well as by backup/restore, this on machine B the owner_sid is invalid. Everything requiring EXECUTE As fails, including loading assemblies from the database.
• tombstoned account. CREATE DATABASE was issued by an user that has left the company. The AD account is deleted and all of the sudden EXECUTE AS mysteriously fails, including loading assemblies.
• disconnected laptop. CREATE DATABASE was issues when the laptop was connected in the work network. At home you can log in using Windows cached credentials, but EXECUTE AS wants to connect to the unavailable AD and fails. Loading assemblies also fails. Problems mysteriously resolves itself next day at work, when you're again within reach of AD.
• spotty AD connectivity. The EXECUTE AS does not uses system cached credentials and connects to the AD every time. If the AD connectivity has issues (timeout, errors) those issues manifest as similar timeouts and errors in EXECUTE AS, including loading assemblies

All these issues can be diagnosed by simply running: EXECUTE AS USER = 'dbo'; in the context of the problem db. It it fails with an error then the cause of your assembly load problems is the EXECUTE AS context of dbo.

The solution is trivial, simply force the owner_sid to a valid login. sa is the usually the best candidate:

ALTER AUTHORIZATION ON DATABASE::[<dbanme>] TO sa;

The funny thing is that the database may seem to be perfectly healthy; tables are available and you can run selects, updates, deletes, create and drop tables etc. Only certain components require EXECUTE AS:

• code signing requires the code to have an EXECUTE AS clause
• assembly validation
• explicit EXECUTE AS in T-SQL code
• Service Broker message delivery (including Query Notifications)

The latter is the most often seen culprit, as applications relying on SqlDependency all of a sudden seem to stop working, or have random problems. This article explains how SqlDependency ultimately depends on EXECUTE AS: The Mysterious Notification