Deploying SQLCLR in Visual Studio -- How to override the generated publish script

Question

Microsoft SQL Server 2019 15.0.2000.5
Microsoft Visual Studio Community 2019 Version 16.11.2
Microsoft .NET Framework Version 4.8.04084
SQL Server Data Tools 16.0.62107.28140

When publishing C# CLR code with Visual Studio, I would like to supply my own script to create some assemblies. In the Build Action, I see options for "pre-deployment" (which I have used successfully) and "post-deployment", but there is not one for just "deployment". Instead VS generates its own assembly creation script, which fails. Because I have one already written that succeeds, I would like to either:

• Get it to use the script I wrote myself or
• Turn off the generation of this script and just use a pre-deployment script

I feel as if this should obvious, but if it is, I have not come up with the right search terms.

The reason for deploying through VS instead of SSMS is so I can debug the code. A result set I am returning from a function is blowing up sometimes. It is my understanding from the MS documentation that I can only debug if I deploy through VS.

Answer 1

As a result of misunderstanding the process, I mischaracterized my question. What I was trying were two different things, neither correct.
With my pre-deployment script, I would:
a) Create the Asymmetric Key
b) Create the login
c) Create the user
d) grant permissions to the login
e) create the assembly
I suspect that might have been OK, if I did not prefix the assembly name with CLR in my script. When the generated script would then attempt to create the assembly, it would get an error based on the existing assembly (but different name), instead of overwriting it. I had thought maybe I needed to tell the generated script to use the other name (or suppress the generation of the script).

So then I tried dropping everything, and running the deployment. My mistaken assumption is that the generated deployment would/could/should write the key, login, user, because it has the SNK info in the project. It, of course, did not do that.

The solution, of course, was for me to remove the assembly creation step from my pre-deployment script, while keeping the creations of the key, login, user. It then created the assembly successfully.