Most likely this relates to some project or other properties that are set in Debug build and not the Release build.
Easiest is to start with a clean and very simple project, and check that everything works there.
Once there, you can build it out by adding the rest of your code, or compare with the problem project.
Follow these instructions:
1. Create a new C# "Class Library" project (not an add-in project or anything like that).
2. Install the "ExcelDna.AddIn" package from NuGet.
3. In the class, add your function (the optional values with defaults aren't supported, so it will be clearer if you leave that out.):
[ExcelFunction(Name = "TEGetCalendar")]
public static string teGetCalendar(string host, string key, string startDate, string endDate, string selectedCntry, string selectedIndic)
{
return "Helo from the TEGetCalendar function";
}
4. Now build and run and check that everything works right.
That should at least sort out the debug / release issues.
-----
You function has a few other red flags that I'll mention, though that's not related to your question about the debug vs release build.
* It's not really supported to use the COM object model (like the COM Range type) from within a UDF. It might work or might not or might make Excel unstable.
* Showing a message box from a UDF (during the calculation) as a form of validation can be very confusing. For example, a user might copy a formula with a mistake into many cells, and the message boxes will pop up and ruin his Excel session.
* Writing to other cells from a UDF can make Excel unstable, breaks Excel's calculation model and makes dependency tracking impossible. Returning an array from your function, and using a utility or helper like the ArrayResizer sample is sometimes a better
approach, though async functions are then not supported.
These are just some comments based on the function you've shown, that might be useful to you or other users.
-Govert