I am using SSDT to create a database containing CLR user defined aggregates.

The aggregates are intended to sit in different schema. That is not possible with CLR objects inside SSDT, without using a post-deployment script to move the objects after deployment.

What I am attempting to do is:

  • Create the CLR aggregates in a single schema (the "CLR" schema) using the "Default schema" option
  • Use a CREATE AGGREGATE wrapper in the desired schema to call the CLR aggregate

For example, I have a CLR aggregate like:

[Microsoft.SqlServer.Server.SqlUserDefinedAggregate(Format.UserDefined, MaxByteSize = -1)]
public struct StatsEntropy : IBinarySerialize
 ... etc

This get compiled and becomes CLR.StatsEntropy in the database. The database is called AnalysisFunctions, so it has an assembly also called AnalysisFunctions. This is no problem.

I then create a wrapper in the Stats schema like so:

CREATE AGGREGATE [Stats].[Entropy]
    @Values FLOAT
EXTERNAL NAME AnalysisFunctions.StatsEntropy

This works without error when I build via debug. I have my debug connection set to a named instance of SQL Server. If I press F5, it compiles and deploys without any problem. The code is now usable on the server, including the wrapper.

But, if I attempt to publish to a server using Publish, it does not work. Instead it fails with:

Errors occurred while modeling the target database. Deployment cannot continue.

There are no further error messages either in the Data Tools Operations panel or error list. ssdttrace shows no useful information:

ssdttrace event log

This only happens when the database already exists on the server. If I drop the database, it can deploy successfully. I can deploy successfully via debug even if the database already exists, it is only via Publish that the problem occurs. I did not start getting this problem until I added the aggregate wrappers.

Previously I was also getting errors indicating that the assembly AnalysisFunctions had an unresolved reference due to the use of EXTERNAL NAME - again working via debug, not via publish. But now that error has mysteriously vanished.

I am using Visual Studio 2017 15.9.21 and SSDT 15.1.62002.01090, deploying to SQL Server 2019.

Does anyone have any idea what this error might be, or how I can debug it?


I can't reproduce this problem using the same version of SSDT as you. I do have a slightly newer Visual Studio (15.9.24), but I'd be surprised if that matters. Here's my (very minimal) setup, please let me know if I've misunderstood some part of your scenario:

SSDT Project

Screenshot of Visual Studio solution explorer showing all the files in my SSDT project






using System;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;

public struct StatsEntropy
    public void Init()
        // Put your code here

    public void Accumulate(SqlString Value)
        // Put your code here

    public void Merge(StatsEntropy Group)
        // Put your code here

    public SqlString Terminate()
        // Put your code here
        return new SqlString(string.Empty);

    // This is a place-holder member field
    public int _var1;

Default Schema

Screenshot of SSDT project properties in Visual Studio, showing default schema of clr and target platform of SQL Server 2019

Normally that failure during preview generation indicates that there are objects in your target database that don't exist in the SSDT model (dacpac). That's discussed on Stack Overflow here: SSDT Publish errors on Creating Publish Preview

You can use the "Schema Compare" feature to check and see if that's the case for you.

If there are no conflicting objects in the target, then it would be helpful if you could edit your question to include your publish settings (the ".publish.xml" file, or at least screenshots of the "Advanced" window when publishing). It could be some odd combination of options causing the problem.

| improve this answer | |
  • Ah yes that's it, I needed to add "Exclude permissions" into the ignore flags in advanced publish settings. It so happens I had added GRANT EXECUTE ANY EXTERNAL SCRIPT since the last time I tried publishing, which it turns out is a property SSDT is unable to model in the target database. I had updated it in debug but not publish script. Sometimes you just need someone to point out the obvious... – Definite 2 days ago
  • @Def a second set of eyes does wonders 😀 Glad I could help! – Josh Darnell 2 days ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.