Last post Jun 21, 2018 09:38 AM by Nan Yu
Jun 20, 2018 09:37 PM|TheNutCracker|LINK
I have followed the instructions on this page:
When I try to connect to the shared instance using the syntax: (localdb)\.\MyIISInstance, it always fails with a message along the lines of 'the system cannot find the file specified'.
The long path to success includes:
But I don't understand why I have to jump through all these hoops to get this to work as the article shows that it should. Can someone give me some tips to connect using the friendly instance name? Thanks for reading!
Jun 20, 2018 10:52 PM|PatriceSc|LINK
Have you tried (localdb)\MyIISInstance rather than (localdb)\.\MyIISInstance ? Or do you really have an extra .\ as part of your instance name (which might confuse LocalDb) ?
Jun 20, 2018 10:59 PM|TheNutCracker|LINK
Yes, I really have the extra .\ because the article explicitly says that represents that you are connecting to a
And it doesn't work when it's removed either.
The instructions are under "Approach 2: Use LocalDB Shared Instance" in the article I posted a link to.
Here is another link to a different article which confirms the proper syntax for connecting to a shared instance of localdb:
EDIT: I think the issue may be related to the fact that my shared instance shows the "Auto-Create" option as being a 'No'. Does anybody know how to change that to a 'Yes'?
Jun 21, 2018 06:43 AM|Nan Yu|LINK
In my opinion , "Auto-Create" may not the reason you can't connect to localdb . Refer to
this thread , if your application uses a version of .NET before 4.0.2 you must connect directly to the named pipe of the LocalDB. I'm not sure why the instance name won't work on your side but specify
the named-pipe address of the instance is a consistent way in different scenarios . What is the error in Windows Event Log and have you tried to restart the instance ?
Jun 21, 2018 08:35 AM|TheNutCracker|LINK
Yes, I'm not very confident that switching 'Auto-Create' to 'on' is the solution to my issue. But I'm desperate right now so I mentioned it.
The thread you posted a link to on SO gives me very much confidence that the way I am connecting is simply a necessary evil to the solution for the specific configuration of software that I'm using.
The thing that puzzles me though is the mention of using any version of ASP.NET "before" 4.0.2. In my Visual Studio solution I have only 2 projects. The independent project targets Framework 4.5 and my dependent project targets Framework 4.7.
And this XML code in my web.config file for the IIS web application that I'm running:
<authentication mode="None" />
<compilation debug="true" targetFramework="4.7" />
<customErrors mode="Off" />
<httpRuntime targetFramework="4.7" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" />
So, I "assumed" I wouldn't have to use the named pipe connection string. From everything I can tell, I am targeting a version much much later than version 4.0.2.
EDIT: However, in IIS Manager all the application pools show targets of ".NET CLR Version = v4.0". The only other choice it offers in the dropdown list is "v2.0".
Thank You for your reply.
EDIT: Okay, I rebooted my PC after changing the computer's name and the friendly connection string works now. I don't think it had anything to do with changing the computer name but then again maybe it did. I probably needed a reboot for other reasons much
sooner than I performed one. So, anyhoo, the article link is valid and I'm good to go. I guess the good old PC reboot remains the most popular troubleshooting technique of all?
Thanks for all the input.
Jun 21, 2018 09:38 AM|Nan Yu|LINK
Yes , we usually will restart the instance to make the instance name to be listened .Glad to know you have solve the issue .