title | description | ms.topic | ms.date | f1_keywords | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
.NET SDK error list |
A complete list of NETSDKxxxx errors, with links to more info where more info is available. |
error-reference |
06/23/2022 |
|
.NET SDK error list
This article applies to: ✔️ .NET 6 SDK and later versions
This is a complete list of the errors that you might get from the .NET SDK while developing .NET apps. If more info is available for a particular error, the error number is a link.
SDK Message Number | Message |
---|---|
NETSDK1001 | At least one possible target framework must be specified. |
NETSDK1002 | Project ‘{0}’ targets ‘{2}’. It cannot be referenced by a project that targets ‘{1}’. |
NETSDK1003 | Invalid framework name: ‘{0}’. |
NETSDK1004 | Assets file ‘{0}’ not found. Run a NuGet package restore to generate this file. |
NETSDK1005 | Assets file ‘{0}’ doesn’t have a target for ‘{1}’. Ensure that restore has run and that you have included ‘{2}’ in the TargetFrameworks for your project. |
NETSDK1006 | Assets file path ‘{0}’ is not rooted. Only full paths are supported. |
NETSDK1007 | Cannot find project info for ‘{0}’. This can indicate a missing project reference. |
NETSDK1008 | Missing ‘{0}’ metadata on ‘{1}’ item ‘{2}’. |
NETSDK1009 | Unrecognized preprocessor token ‘{0}’ in ‘{1}’. |
NETSDK1010 | The ‘{0}’ task must be given a value for parameter ‘{1}’ in order to consume preprocessed content. |
NETSDK1011 | Assets are consumed from project ‘{0}’, but no corresponding MSBuild project path was found in ‘{1}’. |
NETSDK1012 | Unexpected file type for ‘{0}’. Type is both ‘{1}’ and ‘{2}’. |
NETSDK1013 | The TargetFramework value ‘{0}’ was not recognized. It may be misspelled. If not, then the TargetFrameworkIdentifier and/or TargetFrameworkVersion properties must be specified explicitly. |
NETSDK1014 | Content item for ‘{0}’ sets ‘{1}’, but does not provide ‘{2}’ or ‘{3}’. |
NETSDK1015 | The preprocessor token ‘{0}’ has been given more than one value. Choosing ‘{1}’ as the value. |
NETSDK1016 | Unable to find resolved path for ‘{0}’. |
NETSDK1017 | Asset preprocessor must be configured before assets are processed. |
NETSDK1018 | Invalid NuGet version string: ‘{0}’. |
NETSDK1019 | {0} is an unsupported framework. |
NETSDK1020 | Package Root {0} was incorrectly given for Resolved library {1}. |
NETSDK1021 | More than one file found for {0} |
NETSDK1022 | Duplicate ‘{0}’ items were included. The .NET SDK includes ‘{0}’ items from your project directory by default. You can either remove these items from your project file, or set the ‘{1}’ property to ‘{2}’ if you want to explicitly include them in your project file. For more information, see {4}. The duplicate items were: {3}. |
NETSDK1023 | A PackageReference for ‘{0}’ was included in your project. This package is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see {1}. |
NETSDK1024 | Folder ‘{0}’ already exists — either delete it or provide a different ComposeWorkingDir. |
NETSDK1025 | The target manifest {0} provided is of not the correct format. |
NETSDK1028 | Specify a RuntimeIdentifier. |
NETSDK1029 | Unable to use ‘{0}’ as application host executable as it does not contain the expected placeholder byte sequence ‘{1}’ that would mark where the application name would be written. |
NETSDK1030 | Given file name ‘{0}’ is longer than 1024 bytes. |
NETSDK1031 | It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set SelfContained to false. |
NETSDK1032 | The RuntimeIdentifier platform ‘{0}’ and the PlatformTarget ‘{1}’ must be compatible. |
NETSDK1042 | Could not load PlatformManifest from ‘{0}’ because it did not exist. |
NETSDK1043 | Error parsing PlatformManifest from ‘{0}’ line {1}. Lines must have the format {2}. |
NETSDK1044 | Error parsing PlatformManifest from ‘{0}’ line {1}. {2} ‘{3}’ was invalid. |
NETSDK1045 | The current .NET SDK does not support targeting {0} {1}. Either target {0} {2} or lower, or use a version of the .NET SDK that supports {0} {1}. |
NETSDK1046 | The TargetFramework value ‘{0}’ is not valid. To multi-target, use the ‘TargetFrameworks’ property instead. |
NETSDK1047 | Assets file ‘{0}’ doesn’t have a target for ‘{1}’. Ensure that restore has run and that you have included ‘{2}’ in the TargetFrameworks for your project. You may also need to include ‘{3}’ in your project’s RuntimeIdentifiers. |
NETSDK1048 | ‘AdditionalProbingPaths’ were specified for GenerateRuntimeConfigurationFiles, but are being skipped because ‘RuntimeConfigDevPath’ is empty. |
NETSDK1049 | Resolved file has a bad image, no metadata, or is otherwise inaccessible. {0} {1}. |
NETSDK1050 | The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK. |
NETSDK1051 | Error parsing FrameworkList from ‘{0}’. {1} ‘{2}’ was invalid. |
NETSDK1052 | Framework list file path ‘{0}’ is not rooted. Only full paths are supported. |
NETSDK1053 | Pack as tool does not support self contained. |
NETSDK1054 | Only supports .NET Core. |
NETSDK1055 | DotnetTool does not support target framework lower than netcoreapp2.1. |
NETSDK1056 | Project is targeting runtime ‘{0}’ but did not resolve any runtime-specific packages. This runtime may not be supported by the target framework. |
NETSDK1057 | You are using a preview version of .NET. See https://aka.ms/dotnet-support-policy. |
NETSDK1058 | Invalid value for ItemSpecToUse parameter: ‘{0}’. This property must be blank or set to ‘Left’ or ‘Right’ |
NETSDK1059 | The tool ‘{0}’ is now included in the .NET SDK. Information on resolving this warning is available at https://aka.ms/dotnetclitools-in-box. |
NETSDK1060 | Error reading assets file: {0} |
NETSDK1061 | The project was restored using {0} version {1}, but with current settings, version {2} would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore. For more information, see https://aka.ms/dotnet-runtime-patch-selection. |
NETSDK1063 | The path to the project assets file was not set. Run a NuGet package restore to generate this file. |
NETSDK1064 | Package {0}, version {1} was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions. |
NETSDK1065 | Cannot find app host for {0}. {0} could be an invalid runtime identifier (RID). For more information about RID, see https://aka.ms/rid-catalog. |
NETSDK1067 | Self-contained applications are required to use the application host. Either set SelfContained to false or set UseAppHost to true. |
NETSDK1068 | The framework-dependent application host requires a target framework of at least ‘netcoreapp2.1’. |
NETSDK1069 | This project uses a library that targets .NET Standard 1.5 or higher, and the project targets a version of .NET Framework that doesn’t have built-in support for that version of .NET Standard. Visit https://aka.ms/net-standard-known-issues for a set of known issues. Consider retargeting to .NET Framework 4.7.2. |
NETSDK1070 | The application configuration file must have root configuration element. |
NETSDK1071 | A PackageReference to ‘{0}’ specified a Version of {1} . Specifying the version of this package is not recommended. For more information, see https://aka.ms/sdkimplicitrefs. |
NETSDK1072 | Unable to use ‘{0}’ as application host executable because it’s not a Windows executable for the CUI (Console) subsystem. |
NETSDK1073 | The FrameworkReference ‘{0}’ was not recognized. |
NETSDK1074 | The application host executable will not be customized because adding resources requires that the build be performed on Windows (excluding Nano Server). |
NETSDK1075 | Update handle is invalid. This instance may not be used for further updates. |
NETSDK1076 | AddResource can only be used with integer resource types. |
NETSDK1077 | Failed to lock resource. |
NETSDK1078 | Unable to use ‘{0}’ as application host executable because it’s not a Windows PE file. |
NETSDK1079 | The Microsoft.AspNetCore.All package is not supported when targeting .NET Core 3.0 or higher. A FrameworkReference to Microsoft.AspNetCore.App should be used instead, and will be implicitly included by Microsoft.NET.Sdk.Web. |
NETSDK1080 | A PackageReference to Microsoft.AspNetCore.App is not necessary when targeting .NET Core 3.0 or higher. If Microsoft.NET.Sdk.Web is used, the shared framework will be referenced automatically. Otherwise, the PackageReference should be replaced with a FrameworkReference. |
NETSDK1081 | The targeting pack for {0} was not found. You may be able to resolve this by running a NuGet restore on the project. |
NETSDK1082 | There was no runtime pack for {0} available for the specified RuntimeIdentifier ‘{1}’. |
NETSDK1083 | The specified RuntimeIdentifier ‘{0}’ is not recognized. |
NETSDK1084 | There is no application host available for the specified RuntimeIdentifier ‘{0}’. |
NETSDK1085 | The ‘NoBuild’ property was set to true but the ‘Build’ target was invoked. |
NETSDK1086 | A FrameworkReference for ‘{0}’ was included in the project. This is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. For more information, see {1}. |
NETSDK1087 | Multiple FrameworkReference items for ‘{0}’ were included in the project. |
NETSDK1088 | The COMVisible class ‘{0}’ must have a GuidAttribute with the CLSID of the class to be made visible to COM in .NET Core. |
NETSDK1089 | The ‘{0}’ and ‘{1}’ types have the same CLSID ‘{2}’ set in their GuidAttribute. Each COMVisible class needs to have a distinct guid for their CLSID. |
NETSDK1090 | The supplied assembly ‘{0}’ is not valid. Cannot generate a CLSIDMap from it. |
NETSDK1091 | Unable to find a .NET Core COM host. The .NET Core COM host is only available on .NET Core 3.0 or higher when targeting Windows. |
NETSDK1092 | The CLSIDMap cannot be embedded on the COM host because adding resources requires that the build be performed on Windows (excluding Nano Server). |
NETSDK1093 | Project tools (DotnetCliTool) only support targeting .NET Core 2.2 and lower. |
NETSDK1094 | Unable to optimize assemblies for performance: a valid runtime package was not found. Either set the PublishReadyToRun property to false, or use a supported runtime identifier when publishing. When targeting .NET 6 or higher, make sure to restore packages with the PublishReadyToRun property set to true. |
NETSDK1095 | Optimizing assemblies for performance is not supported for the selected target platform or architecture. Please verify you are using a supported runtime identifier, or set the PublishReadyToRun property to false. |
NETSDK1096 | Optimizing assemblies for performance failed. You can either exclude the failing assemblies from being optimized, or set the PublishReadyToRun property to false. |
NETSDK1097 | It is not supported to publish an application to a single-file without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set PublishSingleFile to false. |
NETSDK1098 | Applications published to a single-file are required to use the application host. You must either set PublishSingleFile to false or set UseAppHost to true. |
NETSDK1099 | Publishing to a single-file is only supported for executable applications. |
NETSDK1100 | To build a project targeting Windows on this operating system, set the EnableWindowsTargeting property to true. |
NETSDK1102 | Optimizing assemblies for size is not supported for the selected publish configuration. Please ensure that you are publishing a self-contained app. |
NETSDK1103 | RollForward setting is only supported on .NET Core 3.0 or higher. |
NETSDK1104 | RollForward value ‘{0}’ is invalid. Allowed values are {1}. |
NETSDK1105 | Windows desktop applications are only supported on .NET Core 3.0 or higher. |
NETSDK1106 | Microsoft.NET.Sdk.WindowsDesktop requires ‘UseWpf’ or ‘UseWindowsForms’ to be set to ‘true’. |
NETSDK1107 | Microsoft.NET.Sdk.WindowsDesktop is required to build Windows desktop applications. ‘UseWpf’ and ‘UseWindowsForms’ are not supported by the current SDK. |
NETSDK1109 | Runtime list file ‘{0}’ was not found. Report this error to the .NET team here: https://aka.ms/dotnet-sdk-issue. |
NETSDK1110 | More than one asset in the runtime pack has the same destination sub-path of ‘{0}’. Report this error to the .NET team here: https://aka.ms/dotnet-sdk-issue. |
NETSDK1111 | Failed to delete output apphost: {0}. |
NETSDK1112 | The runtime pack for {0} was not downloaded. Try running a NuGet restore with the RuntimeIdentifier ‘{1}’. |
NETSDK1113 | Failed to create apphost (attempt {0} out of {1}): {2}. |
NETSDK1114 | Unable to find a .NET Core IJW host. The .NET Core IJW host is only available on .NET Core 3.1 or higher when targeting Windows. |
NETSDK1115 | The current .NET SDK does not support .NET Framework without using .NET SDK Defaults. It is likely due to a mismatch between C++/CLI project CLRSupport property and TargetFramework. |
NETSDK1116 | C++/CLI projects targeting .NET Core must be dynamic libraries. |
NETSDK1117 | Does not support publish of C++/CLI project targeting dotnet core. |
NETSDK1118 | C++/CLI projects targeting .NET Core cannot be packed. |
NETSDK1119 | C++/CLI projects targeting .NET Core cannot use EnableComHosting=true. |
NETSDK1120 | C++/CLI projects targeting .NET Core require a target framework of at least ‘netcoreapp3.1’. |
NETSDK1121 | C++/CLI projects targeting .NET Core cannot use SelfContained=true. |
NETSDK1122 | ReadyToRun compilation will be skipped because it is only supported for .NET Core 3.0 or higher. |
NETSDK1123 | Publishing an application to a single-file requires .NET Core 3.0 or higher. |
NETSDK1124 | Trimming assemblies requires .NET Core 3.0 or higher. |
NETSDK1125 | Publishing to a single-file is only supported for netcoreapp target. |
NETSDK1126 | Publishing ReadyToRun using Crossgen2 is only supported for self-contained applications. |
NETSDK1127 | The targeting pack {0} is not installed. Please restore and try again. |
NETSDK1128 | COM hosting does not support self-contained deployments. |
NETSDK1129 | The ‘Publish’ target is not supported without specifying a target framework. The current project targets multiple frameworks, you must specify the framework for the published application. |
NETSDK1130 | {1} cannot be referenced. Referencing a Windows Metadata component directly when targeting .NET 5 or higher is not supported. For more information, see https://aka.ms/netsdk1130. |
NETSDK1131 | Producing a managed Windows Metadata component with WinMDExp is not supported when targeting {0}. |
NETSDK1132 | No runtime pack information was available for {0}. |
NETSDK1133 | There was conflicting information about runtime packs available for {0}. |
NETSDK1134 | Building a solution with a specific RuntimeIdentifier is not supported. If you would like to publish for a single RID, specify the RID at the individual project level instead. |
NETSDK1135 | SupportedOSPlatformVersion {0} cannot be higher than TargetPlatformVersion {1}. |
NETSDK1136 | The target platform must be set to Windows (usually by including ‘-windows’ in the TargetFramework property) when using Windows Forms or WPF, or referencing projects or packages that do so. |
NETSDK1137 | It is no longer necessary to use the Microsoft.NET.Sdk.WindowsDesktop SDK. Consider changing the Sdk attribute of the root Project element to ‘Microsoft.NET.Sdk’. |
NETSDK1138 | The target framework ‘{0}’ is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy. |
NETSDK1139 | The target platform identifier {0} was not recognized. |
NETSDK1140 | {0} is not a valid TargetPlatformVersion for {1}. Valid versions include: |
NETSDK1141 | Unable to resolve the .NET SDK version as specified in the global.json located at {0}. |
NETSDK1142 | Including symbols in a single file bundle is not supported when publishing for .NET5 or higher. |
NETSDK1143 | Including all content in a single file bundle also includes native libraries. If IncludeAllContentForSelfExtract is true, IncludeNativeLibrariesForSelfExtract must not be false. |
NETSDK1144 | Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false. |
NETSDK1145 | The {0} pack is not installed and NuGet package restore is not supported. Upgrade Visual Studio, remove global.json if it specifies a certain SDK version, and uninstall the newer SDK. For more options visit https://aka.ms/targeting-apphost-pack-missing. Pack Type:{0}, Pack directory: {1}, targetframework: {2}, Pack PackageId: {3}, Pack Package Version: {4}. |
NETSDK1146 | PackAsTool does not support TargetPlatformIdentifier being set. For example, TargetFramework cannot be net5.0-windows, only net5.0. PackAsTool also does not support UseWPF or UseWindowsForms when targeting .NET 5 and higher. |
NETSDK1147 | To build this project, the following workloads must be installed: {0}. |
NETSDK1148 | A referenced assembly was compiled using a newer version of Microsoft.Windows.SDK.NET.dll. Please update to a newer .NET SDK in order to reference this assembly. |
NETSDK1149 | {0} cannot be referenced because it uses built-in support for WinRT, which is no longer supported in .NET 5 and higher. An updated version of the component supporting .NET 5 is needed. For more information, see https://aka.ms/netsdk1149. |
NETSDK1150 | The referenced project ‘{0}’ is a non self-contained executable. A non self-contained executable cannot be referenced by a self-contained executable. For more information, see https://aka.ms/netsdk1150. |
NETSDK1151 | The referenced project ‘{0}’ is a self-contained executable. A self-contained executable cannot be referenced by a non self-contained executable. For more information, see https://aka.ms/netsdk1151. |
NETSDK1152 | Found multiple publish output files with the same relative path: {0}. |
NETSDK1153 | CrossgenTool not specified in PDB compilation mode. |
NETSDK1154 | Crossgen2Tool must be specified when UseCrossgen2 is set to true. |
NETSDK1155 | Crossgen2Tool executable ‘{0}’ not found. |
NETSDK1156 | .NET host executable ‘{0}’ not found. |
NETSDK1157 | JIT library ‘{0}’ not found. |
NETSDK1158 | Required ‘{0}’ metadata missing on Crossgen2Tool item. |
NETSDK1159 | CrossgenTool must be specified when UseCrossgen2 is set to false. |
NETSDK1160 | CrossgenTool executable ‘{0}’ not found. |
NETSDK1161 | DiaSymReader library ‘{0}’ not found. |
NETSDK1162 | PDB generation: R2R executable ‘{0}’ not found. |
NETSDK1163 | Input assembly ‘{0}’ not found. |
NETSDK1164 | Missing output PDB path in PDB generation mode (OutputPDBImage metadata). |
NETSDK1165 | Missing output R2R image path (OutputR2RImage metadata). |
NETSDK1166 | Cannot emit symbols when publishing for .NET 5 with Crossgen2 using composite mode. |
NETSDK1167 | Compression in a single file bundle is only supported when publishing for .NET 6 or higher. |
NETSDK1168 | WPF is not supported or recommended with trimming enabled. Please go to https://aka.ms/dotnet-illink/wpf for more details. |
NETSDK1169 | The same resource ID {0} was specified for two type libraries ‘{1}’ and ‘{2}’. Duplicate type library IDs are not allowed. |
NETSDK1170 | The provided type library ID ‘{0}’ for type libary ‘{1}’ is invalid. The ID must be a positive integer less than 65536. |
NETSDK1171 | An integer ID less than 65536 must be provided for type library ‘{0}’ because more than one type library is specified. |
NETSDK1172 | The provided type library ‘{0}’ does not exist. |
NETSDK1173 | The provided type library ‘{0}’ is in an invalid format. |
NETSDK1174 | The abbreviation of -p for —project is deprecated. Please use —project. |
NETSDK1175 | Windows Forms is not supported or recommended with trimming enabled. Please go to https://aka.ms/dotnet-illink/windows-forms for more details. |
NETSDK1176 | Compression in a single file bundle is only supported when publishing a self-contained application. |
NETSDK1177 | Failed to sign apphost with error code {1}: {0}. |
NETSDK1178 | The project depends on the following workload packs that do not exist in any of the workloads available in this installation: {0}. |
NETSDK1179 | One of ‘—self-contained’ or ‘—no-self-contained’ options are required when ‘—runtime’ is used. |
NETSDK1181 | Error getting pack version: Pack ‘{0}’ was not present in workload manifests. |
NETSDK1182 | Targeting .NET 6.0 or higher in Visual Studio 2019 is not supported. |
NETSDK1183 | Unable to optimize assemblies for Ahead of time compilation: a valid runtime package was not found. Either set the PublishAot property to false, or use a supported runtime identifier when publishing. When targeting .NET 7 or higher, make sure to restore packages with the PublishAot property set to true. |
NETSDK1184 | The Targeting Pack for FrameworkReference ‘{0}’ was not available. This may be because DisableTransitiveFrameworkReferenceDownloads was set to true. |
NETSDK1185 | The Runtime Pack for FrameworkReference ‘{0}’ was not available. This may be because DisableTransitiveFrameworkReferenceDownloads was set to true. |
NETSDK1186 | This project depends on Maui Essentials through a project or NuGet package reference, but doesn’t declare that dependency explicitly. To build this project, you must set the UseMauiEssentials property to true (and install the Maui workload if necessary). |
NETSDK1187 | Package {0} {1} has a resource with the locale ‘{2}’. This locale has been normalized to the standard format ‘{3}’ to prevent casing issues in the build. Consider notifying the package author about this casing issue. |
NETSDK1188 | Package {0} {1} has a resource with the locale ‘{2}’. This locale is not recognized by .NET. Consider notifying the package author that it appears to be using an invalid locale. |
NETSDK1189 | Prefer32Bit is not supported and has no effect for netcoreapp target. |
NETSDK1190 | To use ‘{0}’ in solution projects, you must set the environment variable ‘{1}’ (to true). This will increase the time to complete the operation. |
NETSDK1191 | A runtime identifier for the property ‘{0}’ couldn’t be inferred. Specify a rid explicitly. |
NETSDK1192 | Targeting .NET 7.0 or higher in Visual Studio 2022 17.3 is not supported. |
NETSDK1195 | Trimming, or code compatibility analysis for trimming, single-file deployment, or ahead-of-time compilation is not supported for the target framework. For more information, see https://aka.ms/netsdk1195 |
-
#1
При открытии архива записей DVR1604HE-L через SmartPSS (установлен на пк с win10x64) показывает временные отрезки на которых имеется запись, но при попытке запустить воспроизведение любого из фрагментов выдает: Ошибка воспроизведения. Ошибка NETSDK (Failed to start playback. NETSDK returns error — в англ версии). При этом просмотр онлайн видео происходит нормально, проблема только при обращении к архивам.
ПК связывается с регистратором по локальной сети 100мбит, проблема с сетью думаю, что исключена.
версия установленного на ПК SmartPSS — DH_SmartPSS_International_Win32_IS_V2_02_1_R_180619
на регистраторе прошивка стоит 2.606.0018.0
Дата сборки 2010-04-02
Web 2.1.7.21
Возможно стоит обновить прошивку девайса или понизить версию софта на ПК? smartPSS версии 1.0 рекомендованую пользователю с аналогичной проблемой я не нашёл в открытом доступе, прошивку на регистраторе более новую — тоже.
-
27,3 КБ
Просмотры: 13 -
85,9 КБ
Просмотры: 16
-
#3
Старая воспроизводит, спасибо большое!
-
#4
У меня есть клиенты с такими древними DVR-ами, что держу в запасе PSS 4.06 (кто помнит ?). Ну и smartPSS 1.13, 1.16
-
#5
очень древняя программа для тех, кто обнаружил финиш календаря в PSS
-
#6
Smart PSS 2.02.1 при просмотре архива дает «Ошибка воспроизведения Ошибка NETSDK».
Версии 1.12, 1.13, 1.14, 1.16 архив воспроизводят, но при попытке записать в любом формате в любую папку дают «ошибка» или «failed».
Версия ПО регистратора 2.606.0018.0 build 2011-04-26
Windows 7×32 max.
Что еще можно попробовать?
-
#7
См.выше мою вчерашнюю ссылку на дропбоксе.
-
#8
2.606.0018.0 build 2011-04-26
как-то уж ну очень старая. А что за модель?
-
#9
Здравствуйте.
У клиента 30 старых региков, все включены в внутреннюю сеть. И у всех такая же проблема
Ошибка NETSDK.
Старые версии программ тоже не работают. В pss календарь не полностью открывает, не показывает календарь с декабря. Клиент нервничает, менять регики не хочет.. Какие будут советы?
-
#11
Spymax, 16 BNC-портов, S/N PA1HF07701528, Версия ПО регистратора 2.606.0018.0 build 2011-04-26
Шильдика с номером модели с внешних сторон или снизу нет, в настройках регистратора тоже нигде не нашел.
Посмотреть, напишет ли номер модели при включении нет возможности (перезагрузка только в исключительном случае).
CMS DAHUA-HIKVISION-TVT установил, пока не могу настроить тип устройства/номер порта, чтобы увидеть изображение.
-
#12
Модель порты можно посмотреть через веб-интерфейс. Т.к. Spymax это скорее всего Dahua, то порт 37777. Тип — DVR.
-
#13
Модель в веб-интерфейсе также не нашел. Из того, что есть о системе:
Webrec control v.2.1.7.31, NETSDK v.3.3.7.4595, PLAYSDK v.3.31.0.4538, copyright 2008.
Но из веб-интерфейса получилось нужные записи на комп перекинуть, так что пока не найду подходящей проги буду запрашиваемые записи через него доставать.
У охранников онлайн-просмотр через rvi_pss 4.06.6 пока нормально работает.
В программе CMS DAHUA-HIKVISION-TVT устройство определилось (тип устройства dahua_DVR/номер порта 37777), растет лог срабатывания датчиков движения, но не могу настроить онлайн-просмотр и вытащить запись из архива.
-
#14
Решил проблему, делюсь.
Скачал отсюда: https://www.sferann.ru/shop/besplatnyi-soft программу SPYMAX VMS. Пока все работает.
Конвертер H.264 в AVI с этого же сайта при обработке файла архива *.h264 вылетает по ошибке, пара других конвертеров (типа movavi видеоконвертер) тоже отказались.
Файлы архивов с расширением .h264 получилось преобразовать в .avi программкой Dahua AVI Convert (dhavi.exe, установки не требует, работает очень шустро).
-
#15
нашёл закономерность.
регистраторы только с цифрой 1 имеют описанные проблемы .
PA1LQххххххххх
PA1MFххххххххх
PA1Mхххххххххх
PA1LQххххххххх
Запрос в сервис результатов не дал .Они не опознали серийные номера, это было 7-9 лет назад. хотел прошивку поменять.
-
#16
Модель порты можно посмотреть через веб-интерфейс. Т.к. Spymax это скорее всего Dahua, то порт 37777. Тип — DVR.
я смог увидеть серийник и версию п.о. и всё..
-
#17
Укажите PN с наклейки на дне
-
#18
Укажите PN с наклейки на дне
нет возможности. Могу только удаленно зацепится.
-
#19
без PN, я не подберу прошивку.
-
#20
Здравствуйте. Проблема 1 декабря. Дальше архива нет. Онлайн просмотр работает. Не можем посмотреть видео в архиве ни в smart pss, ни в operator 4.05 и 4.06
The other day after installing some windows update, I tried to open Visual Studio. I opened my project and I received an error regarding .Net Sdk.
The project file cannot be opened. Unable to locate the .NET SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.
It was kind of frustrating because I didn’t install anything new I just installed some windows update. Also this can happen for different reasons. So I thought this made me pull my own hair out, maybe by sharing this you don’t have to go through the same.
The .Net Sdk Is Not Actually Installed
First things first, removing some low hanging fruits. First wee need to see if the Sdk is actually installed. Navigate to C:Program Filesdotnetsdk
and see if you can find folders associated with different sdk versions. If you can’t find any folder there that means the sdk is not installed. In that case Install the sdk or repair it if you receive a message about it being already installed. Try running dotnet --list-sdks
command to see if it lists the sdk.
The .Net Sdk Is Installed But it Has Wrong System Type
The thing about the Sdk is that you can’t mix 64x with 86x versions of the sdk. Technically you can but you need to be careful which version of dotnet is going to be selected first. More on this in next section. But if an sdk is installed, be careful you have the correct system type.
The .Net Sdk is Installed But Wrong Dotnet CLI is Trying to Run It
Sometimes you check your dotnet sdk folder and you see the sdk are installed. But when you run dotnet --list-sdks
you don’t see anything. In that case try running list-sdks
command with an absolute path to the correct version of dotnet
. Like C:Program Filesdotnet dotnet –list-sdks, if after running this you see the installed sdk then there are some path problems. You need to check your environment variables to make sure the correct version of dotnet is on your path. More on that in next section.
Dotnet CLI is Not on Your Path (System’s Environment Variable)
We need to first see how dotnet CLI is selected to run our commands. Take a look at this environment variables.
We see here that x64 version of the dotnet is above the x86 version of it. That means the x64 version is going to be selected to run my commands. So now if I only install the x86 version of the sdks, I’m going to have a problem. Because the x64 version of dotnet is unable to use the x86 sdks. What I need to do is to either install the x64 version of the sdk or move the x86 version above x64 version so it can be selected first.
Further Reading and References
Dotnet list-sdks does not list the installed SDKs
Microsoft Visual Studio 2019: The project file cannot be opened. Unable to locate the .NET SDK
.NET SDK not found after successful install
“No SDKs were found” after install “dotnet-hosting-2.1.2-win.exe”
Adventures in .NET Core SDK Installation: Missing SDKs and 32 bit vs 64 bit
Summary
In this post we saw why sometimes the correct sdk is not found on your system. We saw different things we can check for in these cases and how to fix them.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Closed
lgmguto opened this issue
Sep 16, 2017
· 58 comments
Comments
I’m trying to build a solution using msbuild command line and I keep getting this error:
error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
The version of msbuild is the latest from microsoft visual studio 2017 tools. I’m using Windows Server 2012 R2 and the project uses .NET Core 2.0.
This is the command that I’m using:
msbuild.exe /p:Configuration=Release /t:restore C:ProjectsMyProject.sln
I fixed this by creating a path variable «MSBuildSDKsPath» with the value
«C:Program Filesdotnetsdk2.0.0Sdks»
I don’t know why msbuild can’t find this path by default, but this fixed the issue for us
brunis, TraGicCode, subski, CommanderTvis, Karabaev, and vijaykumartk reacted with thumbs down emoji
IgorZudov, webasoo, giavudangle, PMAlexandrovich, and MiniaczQ reacted with laugh emoji
steve-swanson, gandarez, GlebGolovushkin, pjmagee, unquietwiki, RamenTurismo, Tobiaqs, samw2703, clockworkmice, Hokutosei, and 12 more reacted with hooray emoji
cesczacks reacted with confused emoji
steve-swanson, gandarez, chrisdamba, GlebGolovushkin, adrianriepl, pjmagee, 3rdvision, kredenac, Tobiaqs, clockworkmice, and 19 more reacted with heart emoji
beaubgosse, Arzio, webasoo, JakubHolovsky, Levinson02, pizycki, pferreirafabricio, PMAlexandrovich, and MiniaczQ reacted with rocket emoji
nclettiere, omarpiani, thepirat000, PMAlexandrovich, and MiniaczQ reacted with eyes emoji
Anyone who’s still having trouble here, could you try unsetting MSBuildSDKsPath
and see if the issue still repros. If it does, could you set COREHOST_TRACE=1
, reproduce the issue, and then paste the trace output here?
MiniaczQ and JonathanChan1234 reacted with laugh emoji
MiniaczQ reacted with hooray emoji
MiniaczQ reacted with heart emoji
MiniaczQ reacted with rocket emoji
MiniaczQ reacted with eyes emoji
@mayconpires : Any chance you could try setting COREHOST_TRACE=1
per my comment above to give us some data about why this is happening?
@DustinCampbell i just tried unchecking the variable on one of our CI servers…. and now it works without it ???
I have changed a bunch of stuff on there since i wrote the comment though, so idk
I still have the issue for v15.4.8.50001
but setting COREHOST_TRACE=1
does not make any difference in the console output for msbuild.exe.
*Edit:
Initially dotnet build solution.sln
resulted in same error in output (but still reported ‘Build succeeded’). When trying with above COREHOST_TRACE
, dotnet build
spit out tons of log output I could not redirect to a file and now, for whatever reason, dotnet build solution.sln
works fine. Invoking msbuild.exe directly still causes the same error (on server2, on server1 it works fine for same solution).
(I also get error MSB4236: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found
, furthermore we had sdk junction paths in for C:Program Files (x86)Microsoft Visual Studio2017MsBuild15.0Sdks
and ...MsBuildSdks
which both had target to C:Program Filesdotnetsdk1.0.1Sdks
(1.0.1 had been uninstalled), I removed the 2 junction folders and repaired vs2017 build tools, reinstalled netCore 2.0.2 and rebooted. Still same issue.)
To clarify. I was also in the case where i was able to build with dotnet build
, but msbuild /t:rebuild
didn’t work
I still have the issue for v15.4.8.50001 but setting COREHOST_TRACE=1 does not make any difference in the console output for msbuild.exe.
This suggests to me that your msbuild.exe copy does not have the following:
C:Program Files (x86)Microsoft Visual Studio2017EnterpriseMSBuild15.0BinSdkResolversMicrosoft.DotNet.MSBuildSdkResolver
Make sure to install the .NET Core workload:
wgv-srbrills, aminipour, toomastahves, and jbparker reacted with hooray emoji
ryancdotnet, akki, jbparker, and nacitar reacted with heart emoji
Workload selection applies to full VS as well:
If you have Build tools SKU:
- You cannot get Microsoft.NET.Sdk or Microsoft.NET.Sdk.Web to resolve without the .NET Core workload installed.
If you have full VS:
-
You can get Microsoft.NET.Sdk to resolve without the .NET Core or ASP.NET workloads installed, but it will be locked to version 1.x instead of resolving the latest version or global.json implied version.
-
You cannot get Microsoft.NET.Sdk.Web to resolve without the .NET Core workload or ASP.NET workloads installed.
@nguerrera I am using the buildtools, not the full VS. Meaning the .Net Core cross-platform development you have highligted
Meaning the .Net Core cross-platform development you have highligted
… are installed?
You said it started working after changes to build machine. Is it possible the workload installation s one of those changes?
i dont think so. i was having trouble adding a required nuget package to the solution… will be able to give more info when im in office next week
@nguerrera Thanks. That was indeed our problem on server2, it was missing the .net core workload. After including it, it works fine!
I am using VS 2017 15.4.5 and unless I SetEnvironmentVariable’s I get errors in a Test Project and the documents don’t load. If I set it I still get errors loading the projects but they do load. When I build with Visual Studio I get no errors.
Const SolutionPartialPath As String = "roslyn-mastersrcSamplesSamples.sln"
Const BasicCodeAnalysisPartialPath As String = "Roslyn-mastersrcCompilersVisualBasicPortable"
<TestMethod()> Public Sub ElementTypeUnitTestAsync()
Dim registryKey As String
If Environment.Is64BitProcess Then
registryKey = "SOFTWAREMicrosoftVisualStudioSxSVS7"
Else
registryKey = "SOFTWAREWow6432NodeMicrosoftVisualStudioSxSVS7"
End If
Using subKey As RegistryKey = Registry.LocalMachine.OpenSubKey(registryKey)
Dim visualStudioPath As String = TryCast(subKey.GetValue("15.0"), String)
If Not String.IsNullOrEmpty(visualStudioPath) Then
Environment.SetEnvironmentVariable("VSINSTALLDIR", visualStudioPath)
Environment.SetEnvironmentVariable("VisualStudioVersion", "15.0")
Environment.SetEnvironmentVariable("MSBuildSDKsPath", "C:Program Filesdotnetsdk2.0.3Sdks")
End If
End Using
Dim myDoc As String = My.Computer.FileSystem.SpecialDirectories.MyDocuments
Dim SampleSolutionPath As String = Path.Combine(myDoc, SolutionPartialPath)
Dim MS_Workspace As MSBuildWorkspace = MSBuildWorkspace.Create()
AddHandler MS_Workspace.WorkspaceFailed, Sub(sender As Object, e As WorkspaceDiagnosticEventArgs)
Debug.WriteLine(e.Diagnostic.ToString())
End Sub
Dim NewSolution As Solution = MS_Workspace.OpenSolutionAsync(SampleSolutionPath).Result
For Each Project In NewSolution.Projects
Debug.WriteLine($"Project = {Project.Name}")
If Project.Name = "BasicCodeAnalysis" Then
WalkProject(Project)
Exit For
End If
Next
End Sub
Some of the errors
C:UsersPaulM.nugetpackagesmicrosoft.net.compilers2.3.1toolsMicrosoft.VisualBasic.Core.targets: (73, 5): The "Vbc" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
[Failure] Msbuild failed when processing the file '...roslyn-mastersrcSamplesUnitTestProject1UnitTestProject1.vbproj' with message: The imported project "...VSIXProject2CodeRefactoring1.TestbinDebugRoslynMicrosoft.VisualBasic.Core.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. ...VSIXProject2CodeRefactoring1.TestbinDebugMicrosoft.VisualBasic.CurrentVersion.targets
Hi @nguerrera
I have visual studio Build tools installed. I am trying to install .NET Core workload using choco. But that is failing. Is there any official page where i can download .NET Core workload?
@venkateswaris The official way to install the .NET Core workload is either through the Build Tools installer UI or its command line options. Documentation for the command line is here and a list of workloads for the Build Tools installer is here. In your case you probably want to ensure that the Microsoft.VisualStudio.Workload.NetCoreBuildTools
workload is installed.
I’m still getting this error with all three if the fixes mentioned above. All the build tools packages are the latest and visual studio is updated to the latest version as well.
- Path Variable MSBuildSDKsPath
- Build Tools for Visual Studio 2017
- Full Visual Studio 2017 installed with .NET Core Build Tools
[13:47:48][Step 4/9] Executing task: BuildSource
[13:47:49][Step 4/9] Microsoft (R) Build Engine version 15.5.180.51428 for .NET Core
[13:47:49][Step 4/9] Copyright (C) Microsoft Corporation. All rights reserved.
[13:47:49][Step 4/9]
[13:47:49][Step 4/9] C:BuildAgentworkMyProj.csproj : error MSB4236: The SDK ‘Microsoft.NET.Sdk.Web’ specified could not be found.
[13:47:49][Step 4/9] An error occurred when executing task ‘BuildSource’.
[13:47:49][Step 4/9] Error: One or more errors occurred.
[13:47:49][Step 4/9] .NET Core CLI: Process returned an error (exit code 1).
[13:47:49][Step 4/9] Process exited with code 1
- Path Variable MSBuildSDKsPath
@bigswede74 What is PATH and what is MSBuildSdksPath?
Do you have C:Program Files (x86)Microsoft Visual Studio2017EnterpriseMSBuild15.0BinSdkResolversMicrosoft.DotNet.MSBuildSdkResolver ?
@nguerrera I have added the PATH MSBuildSdksPath=C:Program Filesdotnetsdk2.1.4Sdks.
I do have the SdkResolver on the file system at the location above.
@nguerrera I have added the PATH MSBuildSdksPath=C:Program Filesdotnetsdk2.1.4Sdks.
You should not need MSBuildSdksPath to be set at all.
Is C:Program Filesdotnet in your PATH environment variable?
For some reason .NET Core 3 preview’s MSBuild.dll breaks it again and I have to set the path (MSBUILD_EXE_PATH
) to 2.2. (I’m using @RSuter fix). I’m using MSBuild API to load the projects and it fails if MSBUILD_EXE_PATH
is set to 3.0 MSBuild.dll
@dark2201 Can you please open a new issue, describing the conditions you’re in and the exact error? Please tag me when you do.
I ran OmniSharp with COREHOST_TRACE=1
as suggested by @DustinCampbell and could see the following messsage
Searching SDK directory in [/usr/local/bin]
--- Resolving SDK version from SDK dir [/usr/local/bin/sdk]
Checking if resolved SDK dir [/usr/local/bin/sdk/-1.-1.-1] exists
It was not possible to find any SDK version
FWIW, on my machine, dotnet in installed in /usr/lib64/dotnet
and has a link in /usr/bin
.
I looked inside the /usr/local/bin
directory and found a dead symbolic link /opt/dotnet
. I removed the symbolic link, and MSBuild now properly resolves the SDK.
I used my local installation
- Path Variable MSBuildSDKsPath
@bigswede74 What is PATH and what is MSBuildSdksPath?
Do you have C:Program Files (x86)Microsoft Visual Studio2017EnterpriseMSBuild15.0BinSdkResolversMicrosoft.DotNet.MSBuildSdkResolver ?
I used my local VS 2017 installation and copied resolver to build server and problem was fixed.
Tried first MSBuildSdksPath no success
Updated the build tools 2017 to latest version did not work also
Copying my local VS 2017 C:Program Files (x86)Microsoft Visual Studio2017CommunityMSBuild15.0BinSdkResolvers to build server solved for me the issue also!
Ideally an update for build tools for visual studio 2017 package should fix this
@uciprian do you have the «.NET Core Build Tools» workload enabled for your build tools installation?
devel0
referenced
this issue
in devel0/repros
Sep 17, 2019
I stumbled into this problem today, building an app that use roslyn, here there is a repro repository with a Dockerfile based upon mcr.microsoft.com/dotnet/core/sdk:3.0.100-rc1-bionic image.
The program tries to analyze a simple console test source and generate warning at this line, following is the execution of the docker image that can be built and run using this script contained in the repository
Successfully tagged repros/netcore-roslyn-01:latest
------------ENTRYPOINT
3.0.100-rc1-014190 [/usr/share/dotnet/sdk]
dotnet executable = [/usr/bin/dotnet]
PATH = [/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
DOTNET_ROOT = [/usr/share/dotnet]
MSBuildSDKsPath = [/usr/share/dotnet/sdk/3.0.100-rc1-014190/Sdks]
---> OpenProject
Msbuild failed when processing the file '/src/test/test.csproj' with message: The imported project "/app/Current/Microsoft.Common.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. /usr/share/dotnet/sdk/3.0.100-rc1-014190/Sdks/Microsoft.NET.Sdk/Sdk/Sdk.props
---> GetCompilation
has documents = False
UPDATE
fixed by adding MSBUILD_EXE_PATH ( see here )
I ran OmniSharp with
COREHOST_TRACE=1
as suggested by @DustinCampbell and could see the following messsageSearching SDK directory in [/usr/local/bin] --- Resolving SDK version from SDK dir [/usr/local/bin/sdk] Checking if resolved SDK dir [/usr/local/bin/sdk/-1.-1.-1] exists It was not possible to find any SDK version
FWIW, on my machine, dotnet in installed in
/usr/lib64/dotnet
and has a link in/usr/bin
.
I looked inside the/usr/local/bin
directory and found a dead symbolic link/opt/dotnet
. I removed the symbolic link, and MSBuild now properly resolves the SDK.
I did all kind of stuff, this is the only thing that worked form me
I ran OmniSharp with
COREHOST_TRACE=1
as suggested by @DustinCampbell and could see the following messsageSearching SDK directory in [/usr/local/bin] --- Resolving SDK version from SDK dir [/usr/local/bin/sdk] Checking if resolved SDK dir [/usr/local/bin/sdk/-1.-1.-1] exists It was not possible to find any SDK version
FWIW, on my machine, dotnet in installed in
/usr/lib64/dotnet
and has a link in/usr/bin
.
I looked inside the/usr/local/bin
directory and found a dead symbolic link/opt/dotnet
. I removed the symbolic link, and MSBuild now properly resolves the SDK.
This Works Like a charm . Thanks
smaillet
referenced
this issue
in smaillet/Llvm.NET
Feb 20, 2020
add environment variables MSBuildSDKsPath with value «C:Program Filesdotnetsdk2.0.0Sdks» does not work for me.
copy SdkResolvers from local to build server works for me
For me it worked by running dotnet build
instead of using msbuild
@venkateswaris
If you install via choco, you need to include workloads you would normally include via the GUI:
#2532 (comment)
For me, I used this choco command:
choco install visualstudio2019buildtools --package-parameters "--allWorkloads --includeRecommended --includeOptional --passive --locale en-US"
Anyone who’s still having trouble here, could you try unsetting
MSBuildSDKsPath
and see if the issue still repros.
This solved it for me, because previously I had a mixture of standard dotnet SDK installs (via Visual Studio), but also via scoop package manager. I had since removed scoop’s version, but the environment variable was still pointing to the scoop directory. Just deleting the MSBuildSDKsPath
environment variable thus solved it for me.
It would have been nice if the tool output this:
error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found IN THIS FREEKING DIRECTORY: C:asdfasdfasdf
Before adding the MSBuildSDKsPath
env variable you might first want to see if the dotnet.exe is working. You can navigate to where dotnet.exe is (in my case it was «C:Program Filesdotnet») and then execute the command you want to run. I was able to run dotnet tool install -g csharpier
correctly after this. Adding the env variable didn’t help.
Dealing with .NET Core projects in Visual Studio can be tricky, expecially if you’ve installed multiple versions of the SDK and Runtime in your development environment. Among the many issues you can stumble upon, there are the following ones:
«Microsoft.NET.Sdk.Web» is missing
or
«Microsoft.NET.Sdk.Web» specified could not be found
The above error messages will most likely be shown within a pop-up error message that will appear as soon as you try to load/reload a .NET Core project contained in a Visual Studio 2017 solution:
There are a number of causes that could cause this, the most common ones being the following:
- You copied, download or GIT-cloned a project from one computer to another.
- You opened a .NET Core solution file created with a previous version/build of Visual Studio or before updating your local Visual Studio installation.
- You installed a newer version of the .NET Core Runtime and/or SDK (or uninstalled a previous one).
- You messed up with your PATH environment variable(s)
… And so on.
Luckily enough, there are a number of things that can be done to fix that problem for good: let’s see what can we do.
Install the right .NET Core SDK
The first thing to do is to be sure that the right .NET Core SDK and/or Runtime are installed on your system: the most recent builds and versions can be found on the official .NET Core downloads page.
Notice that the .NET Core Runtime alone is only needed if you want to be able to run the executable only: if you require to actively build the production using VS2017 you will need to get the SDK, which does also include the Runtime. Also, if you’re looking to run a specific project developed and built with a specific version of the SDK/Runtime, be sure to get and install it: conversely, if you’re doing that for your own solutions, getting the latest version is highly recommended — you will patch your local project files accordingly.
As soon as you’ve installed the required (or latest) .NET Core SDK and/or Runtime, try to launch your solution file again and see if the issue is gone before proceeding.
Clean-up obsolete .NET Core versions
Having multiple .NET Core Runtimes, SDK and Tooling sets installed might prevent Visual Studio from working properly for a number of reasons: wrong paths, outdated references/project/solution files, and so on. To prevent these kind of issues, you should always be sure to uninstall the .NET Core versions/builds which you don’t require anymore from your development machine.
The best way to do that is to use the good old Control Panel > Programs and Features panel (or Uninstall a Program if your Control Panel is in the category view). If you’re a .NET Core developer from day-one there’s a good chance that it will require some time, as there will be a considerable amount of entries you’ll want to get rid of:
It’s worth noting that you should only uninstall the SDK and Runtime versions/builds you’re sure you don’t need anymore. If you’re a .NET Core developer, there’s a good chance that you might want to keep multiple SDK on your machine to be able to run/compile different projects/solutions… Just be sure to get rid of anything that you’re sure you don’t need anymore, as that will greatly help Visual Studio — and your environment’s .NET Core versioning system in general.
IMPORTANT: While looking at the installed versions/builds, it’s worth checking that you don’t have a runtime conflict between the 32-bit Runtime and the 64-bit SDK or vice-versa: if that’s the case, try to uninstall one of them as explained above, or install the same SDK version for 32-bit and 64-bit.
As soon as you’ve uninstalled everything you need to, check again your solution file again: if the original issue is still there, hop on to the next step(s).
Create a Global.json file
The global.json file has been introduced in may 2017 to allow selection of the .NET Core tools version being used through the
sdk property.
The .NET Core CLI tools look for this file in the current working directory (which isn’t necessarily the same as the project directory) or one of its parent directories. This basically means that, when you run dotnet new or dotnet build, the dotnet host will look in the current folder — and all parent folders up to the drive’s root — for a global.json file and act accordingly:
- If a global.json file is found (and the SDK version it references is installed), then that version will be used for all SDK commands.
- If it can’t find one, it will just use the newest version of the SDK installed on the machine.
It’s worth noting that, back in the day, the global.json file was also used to define the source code folders for a solution, but that functionality was removed with the 1.0.0 SDK. The current file has now a very simple schema, that simply defines which version of the SDK to use:
{ «sdk»: { «version»: «2.0.5» } } |
For further info regarding the global.json file, read the official MS docs.
Rename the SDK reference
According to this StackOverflow answer, renaming the Microsoft.NET.Sdk.web reference to Microsoft.NET.Sdk within the project file might fix the issue, at least in some scenarios. To do that, open your .proj file and replace
<project sdk=«Microsoft.NET.Sdk.web»> with
<project sdk=«Microsoft.NET.Sdk»> .
Add the MSBuildSDKsPath Environment Variable
If all the above methods don’t work, you can try with setting the MSBuildSDKsPath Environment Variable pointing to the required (or latest) .NET Core SDK. In order to do that, open the Windows Control Panel, then select System and go to the Advanced settings in the following way:
As a matter of fact, the dotnet CLI sets the MSBuildSDKsPath environment variable when invoking MSBuild: however, a December 2016 patch changed the CLI behaviour so that it will respect an existing environment variable, if it has already been set: this will allow the developer to «force» the CLI to use a specific SDK.
Check your PATH
It seems that sometimes installing the .NET Core 2.0 SDK will cause issues with the PATH environment variable: verify that both
C:Program Filesdotnet and
C:Program Files (x86)dotnet are in the PATH environment variable.