I have a dialog that works as i expect which is to open a model window and you click cancel or okay and the dialog goes away and the underlying process is excuted or cancelled...when accept is chosen a asynchronous process runs for about 20 seconds....showing a radzen progress bar....
however, when i deploy to the app to iis, the dialog only closes when the underlying process completes. it appears to act like it's synchronous versus asynchronous when run on iis.
I figure there is a setting that is needed in web.config to allow for this to work, not sure considering it appears to work when used with the iis express.
There is no such setting that would control the DialogService behavior - it should work in the exact same way no matter the server.
We haven't seen the described issue so far and will need a sample project that reproduces it. You can send one to info@radzen.com for us to troubleshoot.
since my companies email system will strip out if i try to send a visual studio project for some reason.
could I attach it to a link here? or maybe some other route?
i will try from another email glickerman@hotmail.com and see if that works, thanks.
You can host the project in Dropbox, OneDrive or Google Drive and send us the link over email. If the sample isn't using any sensitive data you can link it in here as well.
i have found that the issue does not occur on first publish to a site... works as expected on first run...
after that....all other calls using dialog for long running process leaves the dialog until my process completes..i can restart the site, issue still exists...but if it delete the data for site, publish again, run it , works first time only...
i have spent all week troubleshooting this and i could really use a tip to help me solve this as I really like dialogs. Maybe you have ideas of how i can troubleshoot what may be occuring such that the dialog does not close?
i also noted that this works on my local iis running on windows 10 using a slightly higher version than is running on a server 2016 server where the issue occurs after first run.
Sounds like there is something about server 2016 and iis?
I found it amusing about web sockets because last week before all of this....I had found a post about how BLAZOR uses web sockets and yet...it was working without it, but after i configured it, i noticed now there was open sockets on IIS that was not there before. with or without it, i think when you don't have it installed it has a LITE version that makes it function, but not full version.anyways. i digress...
something else that may play a role here i have not mentioned is that i use windows authentication
i don't use the typical web login type thing, but i do use a table to verify that your credentials are in a table and then it opens page...all data is using either scoped or intrisic for data
after more testing today....
i think this issue occurs and is somehow related to that if you connect from muliple computers it creates the issue....it seems a site initializes something from computer 1 that then makes it fail the dialogs on machine # 2 you run site from...
but if you stop site, start site, try from machine # 2, then it works mutliple times, it's when you introduce another connection for same user on diff machine is what appears to be the issue.
i can even get it to fail on my windows dev machine...
i can get the other machine to keep working if i only use it...
you could make the case that most will only use one machine, but that is counter to the web culture!!!
any ideas if what i'm referring to triggers anything that you do in dialog service that could maybe created this issue that leaves dialog open?
Blazor Server uses SignalR which by default runs on websockets then falls back to other transport types. I don't know if this is related to your case or not but is one important difference between using IIS and the default dotnet web server.
I am really shooting in the dark here but it could be related to the dialog service DI scope. Still I can't be sure without reproducing the problem first. Or it could be another service that you are using. Look for services with Singleton scope - those tend to cause problems with multiple users.
