2017-03-04 58 views
12

有沒有人在.NET Core 1.1中看到過一個問題,在netcoreapp1.1 \ publish文件夾下面,他們最終會看到一個bin文件夾,它似乎會自行循環並最終導致路徑長信息出現在Windows中。試圖在Windows資源管理器中刪除此文件夾會導致出現「源太長」消息。唯一的解決方案是使用RoboCopy.net核心中的瘋狂深度路徑長度1.1

這裏是所生成的路徑中的一個的示例:

BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \調試\ netcoreapp1.1 \發佈\ BIN \發佈\ netcoreapp1.1 \發佈\ BIN \發佈\ netcoreapp1.1 \發佈\ BIN \發佈\ netcoreapp1.1 \發佈\ BIN \發佈\ netcoreapp1.1 \發佈\ BIN \發佈\ netcoreapp1.1 \發佈\ Controllers \

這是由我設置不正確的東西引起的問題嗎?

最後清理返​​回以下數據:

文件夾:6866個 文件:7391

我使用下面的命令發佈:

dotnet publish -c debug 

似乎每個發佈,使文件夾結構更深,這似乎與我的項目中創建此文件夾結構中的CSHTML文件有關:

\publish\bin\debug\netcoreapp1.1\publish\Controllers\Account\Views 

然後在第二內建這樣的結構:

\publish\bin\debug\netcoreapp1.1\publish\bin\debug\netcoreapp1.1\publish\Controllers\Account\Views 

等等......

我使用SDK 1.0.0-preview2-1-003177

+0

如果我正確地閱讀這個,該嵌套的文件夾結構實際上存在於磁盤上? –

+0

此外,我不認爲你將能夠用Windows資源管理器刪除該文件夾,因爲該程序在很多方面受到MAX_PATH定義(260)的限制。你可以編寫一個程序來爲你刪除文件夾。編輯:我想Robocopy也可以。真正的問題是路徑大於MAX_PATH –

+0

你是如何發佈它的? – Pawel

回答

6

我記得我有同樣的問題與.NET核心SDK的preview2它固定在任何preview3或preview4它。如剛纔更新你的SDK https://www.microsoft.com/net/download/core#/sdk

隨着新的SDK你的項目將被轉換爲csproj和MSBuild,所以沒有project.json了。

編輯:項目將在VS 2017中自動轉換,如果使用命令行工具,則應該應用dotnet-migrate命令。

2

嘗試更新的SDK現在發佈版本可用。 版本1.0和版本1.1(從這篇文章發表時)包含在一個包中,從這裏下載。 https://www.microsoft.com/net/download/core

正如@Andrii Litvinov所提到的,遷移將發生在VS2017。如果您需要幫助,請致電: :Microsoft爲projectbuilder提供免費的移植幫助。 (由於本次更新的時間2017年3月15日]

退房:http://landinghub.visualstudio.com/migrate-dotnetcore

+0

查找字符串的最佳位置需要添加到global.json文件以表明它應該使用最新的SDK,即「」1.0.0-preview2-1-003177「」部分? –

+0

@MichaelEdwards它不是作爲環境一部分的項目的一部分。您需要下載並升級您的Dev環境。 – Marc

+0

我已經運行更新EXE,但我不知道什麼字符串值我現在應該用於Global.json。是否應該自動更新? –