Configuring the location of LINQPad.UserQuery.exe

philip_atz

This is essentially a question about LINQPad configuration. I tried posting it on StackOverflow (link) and didn't get any answers, but I guess the LINQPad user forum is a better place to ask.

I am trying to perform a SQL query, in LINQPad, with impersonation but the impersonating user does not have access to the original user's AppData folder, which causes my SqlConnection constructor to throw a TypeInitializationException:

using (var db = new SqlConnection(ConnectionString))
{
    // ...
}

The InnerException here is a FileNotFoundException on the actual executable for the LINQPad query:

C:\Users\MyUser\AppData\Local\LINQPad\ProcessServer5AnyCPUB\LINQPad.UserQuery.exe

There was a workaround suggested here, which doesn't work for me. It simply changes my inner exception to:

Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))

Is there some way for me to configure that folder so that LINQPad will try to run with an executable in a location accessible by all user accounts? I have looked at LINQPad's preferences but I couldn't find any place to specify the folder for the LINQPad.UserQuery.exe

JoeAlbahari

After applying the suggested workaround, can you run queries other than the one in question?

If so, it's likely that the workaround is doing its job, and that LINQPad.UserQuery is running from a location accessible to all user accounts. The catastrophic failure is the next hurdle in getting this to work.

Does the following help?

https://stackoverflow.com/questions/12791207/catastrophic-failure-when-impersonate-other-user

https://social.msdn.microsoft.com/Forums/lync/en-US/90e313c6-bf2f-45ac-a595-a7b6c4aae7e1/windowsidentityimpersonate-throws-catastrophic-failure-exception-from-hresult-0x8000ffff?forum=windowssecurity

philip_atz

Thank you Joe! The second link you sent helped me a lot!

I ended up moving the impersonation so that it only captures db.Open() instead of capturing the constructor call to SqlConnection(ConnectionString). From what I understood, impersonating the constructor call was causing problems because the SqlConnection constructor tries to read various configs from places it might not have access to.