SOE file not built

Question

I have quite a few C# projects, REST SOEs based on ArcObjects (.NET 4.5) or ArcGIS Pro (.NET 6.0). Visual Studio (2019) shows no errors, and warnings appear in the ArcGIS Pro projects only. Everything compile well, the .dlls are made correctly, but there are no config.xml and .soe files. Well, not always - I made this work in about a half of the projects. The ArcGIS Pro projects are of low priority now, but one ArcObjects project still doesn't make the two files, and I have no idea why.

To finish the other projects, I did...

• restart and delete .vs, bin and obj folders many times
• reinstall ArcGIS Developer Kit and ArcGIS Enterprise (both 10.8)
• make sure that the path for the .targets file is correct in the Import Project section of the .csproj file
• set the TargetVersion in AssemblyInfo and the AddInTargetVersion in the .csproj file are set to the correct version of ArcGIS (10.8)
• make sure that the relevant references are of the appropriate versions, especially the ESRI.Server.X or ESRI.ArcGIS.X ones (where X is SOESupport or some other library correcponding to the ArcGIS Developer Kit or ArcGIS Server)
• set the references' properties Copy local, Specific version and Embed interop types to false
• experiment with removing and adding references
• sign all the libraries made by my company used by the projects
• set a supported ToolsVersion in the .csproj file (for VS 2019, 14 seems good)
• try all the possible configurations (x86, x64, Any CPU, both Release and Debug)

What was suggested but didn't work:

• adding .11. or some other number to the .targets file name
• trying different .targets files

I made all this in the project in question as well. I try to compare the projects as thoroughly as possible, but I can't find any difference that could affect the .soe file production. Where else could be the problem?

Answer 1

In the same solution, I've created another project of the same template (REST SOE Template (ArcMap)) and copied my code there. It worked. I must have broken something while trying to fix this or (more probably) some other error.