Build and Deploy Issues After Modifying this Solution

Sep 18, 2015 at 9:21 PM
Edited Sep 18, 2015 at 9:23 PM
I've been working on making changes to this solution to make it more robust. I was able to make changes and build 3 or 4 new versions that installed and ran find on our Live DNN site.

Eventually, the builds would quit working when installed on from the .ZIP package. The problem would manifest itself when the call to the controller's send action via the Submit button on the Invite form/module.

The Chrome Developer Tools would give a message like this..

Unable to locate a controller for http://www.dnnsite.com/DesktopModules/SocialInvite/API/invite/send. Searched in namespaces: DotNetNuclear.Modules.InviteRegister.Services.Controllers.

...I never touched any of the code that defines the controller or the action.

The project and code works fine on my development machine. It just won't work when installed from the .ZIP file that is created.

I've tried different development machines, different versions of DNN Evoq Engage from around 7.3 (I guess it was called "Social" then) to 8.1 which is what we are running now. I've tried fresh installs of DNN on multiple machines as well.

I'm new to using the DNN WebAPI that is failing, so I've had multiple DNN Module "experts" look at it and they haven't been able to come up with any ideas. Even DNN Support went "above and beyond" to look at the solution and couldn't come up with any ideas.

It seems that the problem is with the build and/or deploy process since it works just fine on a development machine with the solution in the DesktopModules/DotNetNuclear.InviteRegister folder. I've even copied our live site to my development machine and replaced the contents of the "DesktopModules/DotNetNuclear.InviteRegister" with the solution and it works there, so it isn't an incompatibility with files on the Live site.

Has anyone else had problems like this? I've tried to turn on as much debugging and logging as I can; e.g. setting the EnableServicesFrameworkTracing set to True. I've seen other people have the same type of issue on other modules and their suggestions were to try using the DNN source code version to debug. Since we are running Evoq Engage, the source code version isn't available to us.