Hi,
Create a new ASP.Net Core application in Visual Studio Community 2015 Update 3 on Windows 10 with latest Dotnet CLI (preview3-003686) and VS Tooling (VS2015Tools.Preview2.0.2). Point nuget.config to aspnetcore-dev myget feed.
When ever I create a new ASP.Net Core Project in Visual Studio community 2015 update 3, the first package restore (which happens immediately after project creation) fails with following error. In fact the same error is coming even if we do restore packages (by right clicking references of the project).
PATH=.\node_modules\.bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\git
C:\Program Files\dotnet\dotnet.exe restore "C:\Users\ramiadmin\Desktop\SampleApp\.vs\restore.dg"
error: Error reading 'C:\Users\ramiadmin\Desktop\SampleApp\.vs\restore.dg' at line 0 column 0 : Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
error: Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
Interesting point it, if I dot dotnet restore
from command line, it successfully restore all the packages. Also dotnet run
from command line works absolutely fine.
I pointed my nuget.config
to aspnetcore-dev
myget feed -
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://dotnet.myget.org/F/aspnetcore-dev/api/v2/" />
</packageSources>
<disabledPackageSources>
<add key="Microsoft and .NET" value="true" />
</disabledPackageSources>
</configuration>
Following is my global.json -
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview3-003686"
}
}
Following is my project.json -
{
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1",
"type": "platform"
},
"Microsoft.ApplicationInsights.AspNetCore": "1.0.0",
"Microsoft.AspNetCore.Diagnostics": "1.1.0-*",
"Microsoft.AspNetCore.Mvc": "1.1.0-*",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.0.0-*",
"type": "build"
},
"Microsoft.AspNetCore.Routing": "1.1.0-*",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0-*",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0-*",
"Microsoft.AspNetCore.StaticFiles": "1.1.0-*",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0-*",
"Microsoft.Extensions.Configuration.Json": "1.1.0-*",
"Microsoft.Extensions.Logging": "1.1.0-*",
"Microsoft.Extensions.Logging.Console": "1.1.0-*",
"Microsoft.Extensions.Logging.Debug": "1.1.0-*",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0-*",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0-*"
},
"tools": {
"BundlerMinifier.Core": "2.0.238",
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-*",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"
},
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
}
},
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},
"runtimeOptions": {
"configProperties": {
"System.GC.Server": true
}
},
"publishOptions": {
"include": [
"wwwroot",
"**/*.cshtml",
"appsettings.json",
"web.config"
]
},
"scripts": {
"prepublish": [ "bower install", "dotnet bundle" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
}
Either after the initial application creation or by selecting restore packages (by right clicking references in VS), Packages should be restored successfully with out errors.
.NET Command Line Tools (1.0.0-preview3-003686)
Product Information:
Version: 1.0.0-preview3-003686
Commit SHA-1 hash: 038fb6fbaeRuntime Environment:
OS Name: Windows
OS Version: 10.0.10586
OS Platform: Windows
RID: win10-x64
I used Visual Studio Community 2015 Version 14.0.25425.01 Update 3
.
I have installed Visual Studio 2015 Tooling Preview 2 of version DotNetCore.1.0.1 - VS2015Tools.Preview2.0.2
from https://go.microsoft.com/fwlink/?LinkId=827546
OS - Windows 10 Enterprise N
Same problem
The problem on Windows may been fixed?
Tried restore, build, publish
using command line on windows, succeed.
But the same problem still on CentOS, using same CLI preview3-003701
.
Cannot compile on centos any more...
Same...
PATH=.\node_modules\.bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\git
C:\dotnet\dotnet.exe restore "D:\User\CoreProjects\Sample\.vs\restore.dg"
error: Error reading 'D:\User\CoreProjects\Sample\.vs\restore.dg' at line 0 column 0 : Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
error: Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
I don't know if this is the same issue: dotnet/sdk#6008
And the same problem on CentOS7:
Compiling SampleDLL1 for .NETStandard,Version=v1.6
Compilation succeeded.
0 Warning(s)
0 Error(s)
Time elapsed 00:00:01.3011408
Project SampleDLL2(.NETStandard,Version=v1.6) will be compiled because dependencies changed
Compiling SampleDLL2 for .NETStandard,Version=v1.6
Compilation succeeded.
0 Warning(s)
0 Error(s)
Time elapsed 00:00:01.0493847
Illegal characters in path.
Parameter name: path
Published 0/1 projects successfully
Even if i change the CLI back to preview3-003233
, the same problem occurred.
These are CLIs i tried:
Product Information:
Version: 1.0.0-preview3-003223
Commit SHA-1 hash: 9d3b727392
Runtime Environment:
OS Name: centos
OS Version: 7
OS Platform: Linux
RID: centos.7-x64
Product Information:
Version: 1.0.0-preview3-003701
Commit SHA-1 hash: 3da55881b5
Runtime Environment:
OS Name: centos
OS Version: 7
OS Platform: Linux
RID: centos.7-x64
Product Information:
Version: 1.0.0-preview3-003701
Commit SHA-1 hash: 3da55881b5
Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Product Information:
Version: 1.0.0-preview3-003686
Commit SHA-1 hash: 038fb6fbae
Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Same... if I remove the '#:' from restore.dg, it's written back there when I try again.
Command line works. In VS failed.
@EncoderPtd I am not sure if I got you correctly. How is it related to file name? I created a brand new application with latest dotnet cli. And my application name is SampleApp
. So what should be changed?
Which file actually caused problem to you?
@EncoderPtd My application was brand new, created with VS. I never changed a single file in it. Except I updated global.json
with new sdk version and project.json
with new versions (I am sure that these versions are available in MyGet). So I think my problem is completely different. Waiting for someone from Core team to reply.
In the mean time, I will make my project available in github and link it here.
Same thing here :/ Happens during restoring nuget packages. This operation fails and #:
is being added at the beginning some lines (mostly first line) in the restore.dg
file on every package restore try.
It results in 'Package restore failed' error in Output:
[file path] at line 0 column 0 : Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
error: Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
Thus, some of the references, have yellow warning sign instead of icons, but solution builds successfully anyway.
I'm having the same problem. Package restore inside VS2015 fails with the message:
error: Error reading 'C:\Users\username\Documents\Projects\SampleApp\.vs\restore.dg' at line 0 column 0 : Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
However, dotnet restore
from command line completes without any problems.
Using latest version of dotnet
(1.0.0-preview3-003786) and VS2015 Update 3.
I'm having the same issue. I'm following this thread.
Yep
Same issue
I'm also experiencing the same issue.
Same issue with '#:'. But I can open powershell and run dotnet restore and all packages restore correctly. Beeezaaar!
Folks, when Preview3 ships it will not include project.json support. In fact, builds since 3393 have already moved all major verbs [new, restore, build, pack, publish, etc...] to work with .csproj files only. There is a new dotnet migrate
verb in preview3 that will convert your project.json project into a csproj project. Of course, the preview tooling you have installed for project.json won't be able to deal with the csproj version yet, but you can get a feel for where things are headed.
When we shipped VS tools for project.json, the project templates included a global.json file that specified the preview2 version of the tools for any projects created in visual studio. You will want to be sure that your project.json solutions include a global.json with a sdk version so as to avoid problems in Visual Studio when you have a preview3 build installed.
Specifically, in most projects you will want [I say most because you may have installed later preview2 builds. If you see problems, just match to the preview2 version you have been using]:
{
"sdk": {
"version": "1.0.0-preview2-003121"
}
}
There may be a deeper issue here than folks using preview3 with project.json, so I'll leave the issue open for a while so we can discuss.
I'm still on "sdk": {
"version": "1.0.0-preview2-003133"
}
The restore process fails, but dotnet restore works. (restore.dg has #: as first chars)
Thanks for the info, looking forward to preview3. Cheers
@piotrpMSFT Is there any chance this will change? The hard migration of projects, repositories, and IDEs all at once is a _huge_ ask for any project. The current plan is a stop-the-world operation and a major pain for any team that has given a lot of time to come along on this journey and help improve things along the way. It's even worse for open source which has pull requests involved.
I strongly urge Microsoft to reconsider this support split, unless we want quite a few projects to linger on project.json. I know I wouldn't migrate our projects (indefinitely) with the current roadmap; it's just too big of an ask if all we can do is a highly coordinated big bang changeover.
@NickCraver I assume its not by design as you can do a command line restore, then VS will happily build - it just has issues restoring due to the restore.dg file which the cli doesn't seem to use but VS does.
@benaadams re-reading that I see I should have clarified: I was speaking specifically about supporting project.json
in VS 2015 (14) _only_ and supporting the new .csproj
in VS 15 _only_. That's an incredibly bad constraint and I'd even say feels like punishment for any early adopters, especially people multi-targeting in project.json
today.
Folks, we just posted a nice writeup of options for working around this issue:
https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/ProjectJsonToCSProj.md
I think that everyone can find an approach that works for them, whether wanting to work with project.json, csproj, or both. Please take a look and let us know if this gets you unblocked!
Folks, we got reports from a number of machines which still repro the issue after following the steps in the linked writeup. Unfortunately, we haven't been able to reproduce the issue and need some assistance to get this addressed.
If you followed the guidance in the writeup and still see an issue can you please share some state with us?
Program Files\dotnet
and Program Files (x86)\dotnet
directories on your machine.global.json
file for your solutionThese should give us enough data to find out why some folks are still running into issues. You can put these all in an archive and send me a link at piotrp [at] microsoft [dot] com. I'd really like to get to the bottom of the remaining issue!
@cehager thanks for helping out with a repro!
Folks we were able to track down the cause of the .dg issue. As a workaround you can:
C:\Program Files\dotnet\dotnet.exe restore "C:\Users\ramiadmin\Desktop\SampleApp\.vs\restore.dg"
cd C:\Users\ramiadmin\Desktop\SampleApp\
I've tested this locally and was able to F5 and debug. Keep in mind, the procedure will need to be repeated any time that a restore would be required, so on a new machine or when dependencies change.
Closing the issue since there is a workaround. Working on a better fix...
Most helpful comment
Same thing here :/ Happens during restoring nuget packages. This operation fails and
#:
is being added at the beginning some lines (mostly first line) in therestore.dg
file on every package restore try.It results in 'Package restore failed' error in Output:
[file path] at line 0 column 0 : Unexpected character encountered while parsing value: #. Path '', line 0, position 0. error: Unexpected character encountered while parsing value: #. Path '', line 0, position 0.
Thus, some of the references, have yellow warning sign instead of icons, but solution builds successfully anyway.