DevExtreme MVC - ConvertToDevExtremeCommandPackage throws the "Empty path name is not legal" error at the project startup

Me too. This is in the log.

C#
  <entry>  
    <record>734</record>  
    <time>2019/02/13 11:21:50.094</time>  
    <type>Error</type>  
    <source>VisualStudio</source>  
    <description>SetSite failed for package [ConvertToDevExtremeCommandPackage]Source: &apos;mscorlib&apos; Description: Empty path name is not legal.&#x000D;&#x000A;System.ArgumentException: Empty path name is not legal.&#x000D;&#x000A;   at System.IO.File.ReadAllText(String path)&#x000D;&#x000A;   at DevExtreme.AspNet.Mvc.ProjectWizards.FileSystemImpl.ReadAllText(String fileName)&#x000D;&#x000A;   at DevExtreme.AspNet.Mvc.ProjectWizards.ProjectHelper.IsNETCoreProjectType()&#x000D;&#x000A;   at DevExtreme.AspNet.Mvc.ProjectWizards.ProjectHelper.IsDevExtremeMvcNetCoreProject()&#x000D;&#x000A;   at DevExtreme.AspNet.Mvc.VisualStudio.ConvertToDevExtremeCommand.CheckAndSuggestUpdateForProjects()&#x000D;&#x000A;   at DevExtreme.AspNet.Mvc.VisualStudio.ConvertToDevExtremeCommand..ctor(Package package, DTE2 dte, OleMenuCommandService commandService, Boolean isSolutionOpened)&#x000D;&#x000A;   at DevExtreme.AspNet.Mvc.VisualStudio.ConvertToDevExtremeCommand.&lt;Initialize&gt;d__23.MoveNext()&#x000D;&#x000A;--- End of stack trace from previous location where exception was thrown ---&#x000D;&#x000A;   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)&#x000D;&#x000A;   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)&#x000D;&#x000A;   at DevExtreme.AspNet.Mvc.VisualStudio.ConvertToDevExtremeCommandPackage.&lt;InitializeAsync&gt;d__2.MoveNext()&#x000D;&#x000A;--- End of stack trace from previous location where exception was thrown ---&#x000D;&#x000A;   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)&#x000D;&#x000A;   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)&#x000D;&#x000A;   at Microsoft.VisualStudio.Shell.AsyncPackage.&lt;&gt;c__DisplayClass16_0.&lt;&lt;Microsoft-VisualStudio-Shell-Interop-IAsyncLoadablePackageInitialize-Initialize&gt;b__1&gt;d.MoveNext()&#x000D;&#x000A;--- End of stack trace from previous location where exception was thrown ---&#x000D;&#x000A;   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()&#x000D;&#x000A;--- End of stack trace from previous location where exception was thrown ---&#x000D;&#x000A;   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)&#x000D;&#x000A;   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)&#x000D;&#x000A;   at Microsoft.VisualStudio.Services.VsTask.RethrowException(AggregateException e)&#x000D;&#x000A;   at Microsoft.VisualStudio.Threading.JoinableTask.&lt;JoinAsync&gt;d__78.MoveNext()&#x000D;&#x000A;   at Microsoft.VisualStudio.Services.VsTask.InternalGetResult(Boolean ignoreUIThreadCheck)&#x000D;&#x000A;   at Microsoft.VisualStudio.Services.VsTask.GetResult()</description>  
    <guid>{429DCF35-B2B1-4480-A1D7-0422AADB85B9}</guid>  
    <hr>80070057 - E_INVALIDARG</hr>  
    <errorinfo></errorinfo>  
  </entry>  
  <entry>  
    <record>735</record>  
    <time>2019/02/13 11:21:50.100</time>  
    <type>Error</type>  
    <source>VisualStudio</source>  
    <description>End package load [ConvertToDevExtremeCommandPackage]</description>  
    <guid>{429DCF35-B2B1-4480-A1D7-0422AADB85B9}</guid>  
    <hr>80070057 - E_INVALIDARG</hr>  
    <errorinfo></errorinfo>  
  </entry>  
</activity>  

Also I noticed that "DevExtreme" became the default in the Output Window "Show output from" dropdown.
Where has all this DevExtreme stuff come from? I am a Winforms-only developer!

Hi Simon,

We checked this issue and found that ConvertToDevExtremeCommandPackage fails to start if there are no certain .NET Core packages in Visual Studio. We'll update this thread once we correct this logic. Please bear with us.
We reproduced the second issue as well. It occurs because now DevExtreme Tools are loaded for each VS project. Although it doesn't affect VS operation, we understand that this may be inconvenient and will improve this logic to check for a project type in future versions.