Cs0234 c как исправить

Ошибка CS0234 при попытке обратится к коду из папки Editor

Начну я вот с чего: рантайм код ни в коем случае не должен ссылаться на Editor код.

Во-первых, это чисто с точки зрения не совсем понятная логика, Editor код предназначен для редактора, а не для игровой логики. Во-вторых, любые Editor скрипты никогда не попадают в билды.

Scripts placed in a folder called Editor are treated as Editor scripts rather than runtime scripts. These scripts add functionality to the Editor during development, and are not available in builds at runtime.

You can have multiple Editor folders placed anywhere inside the Assets folder. Place your Editor scripts inside an Editor folder or a subfolder within it.

В данном конкретном случае все скрипты в папках с названием «Editor» и их подпапках будут скомпилированы в отдельную dll’ку, когда все остальные .cs файлы будут скомпилированы в другую dll’ку, между ними никаких связей нет, поэтому и возникла ошибка из вопроса. Решаемо ли это? Чисто теоретически можно указать взаимосвязь между этими библиотеками, но в рантайме этот код все равно не будет работать.

VS 2015 CS0234 Ложная ошибка

В настоящее время у меня есть решение с 2 проектами. 1 проект имеет прямую ссылку на другой проект, оба .net 4.5. Для простоты я назову проект, на который ссылается «А», а проект, который ссылается на А — «Б».

При разработке в B у меня есть полный IntelliSense для классов в A. Как только я создаю решение, проект A строится успешно, но проект B имеет несколько ошибок как таковых:

Тип или имя пространства имен «x» не существует в пространстве имен «projectName» (отсутствует ссылка на сборку?)

Когда я дважды щелкаю по ошибке, чтобы перейти к файлу, я вижу ошибку в операторе ‘using’ в течение приблизительно 1 секунды, затем она исчезает вместе с ошибкой из списка ошибок. Я могу продолжать просматривать весь список ошибок до тех пор, пока список ошибок не станет пустым, но как только я восстановлю ошибки, они снова появятся.

Любая помощь была бы очень признательна.

3 ответа

Убедитесь, что проект B ссылается на другие dll-файлы, которые используют более высокую версию Framework, чем 4.5, также я столкнулся с этой проблемой из-за некоторых пакетов Nuget, которые должны были быть добавлены в каждый проект, который ссылался на исходный с помощью пакета.

У вас есть ссылка на файл или проект. Если это ссылка на файл (т. Е. Вы указали на выходную dll проекта A), то вам нужно убедиться, что зависимости проекта говорят, что B зависит от A, так что они построены в правильном порядке.

Попробуйте взглянуть на ваши зависимости проекта. Для этого: Щелкните правой кнопкой мыши на своем решении и выберите «Свойства». Затем в левой части экрана выберите «Зависимости проекта». Убедитесь, что проект «B» зависит от проекта «A».

Это гарантирует, что проекты строятся в правильном порядке. Это уже должно быть установлено таким образом, но иногда Visual Studio неправильно устанавливает зависимости.

Кроме того, убедитесь, что у вас нет ссылок на проект «А» в проекте «Б». Это создаст круговую зависимость и не даст вам конца печали.

Error CS0234: The type or namespace name ‘TestPlatform’ does not exist in the namespace ‘Microsoft.VisualStudio’ #2312

I’m trying to compile our tests with the new SDK and we’re facing this issue for platforms «x86» and «AnyCPU» when using «Microsoft.NET.Test.Sdk» version 16.4.0.

Error CS0234: The type or namespace name ‘TestPlatform’ does not exist in the namespace ‘Microsoft.VisualStudio’

It worked fine for v15.9.0 and we never had any issues. We’d like to upgrade to a later version, but this issue is kind of confusing.

Please refer jobs:

Win10Enclave AnyCPU,Release,netfx,true
Win10Enclave x86,Release,netfx,true

This issue does not occur when building locally on Developer command prompt on the same machine using same steps where this is occurring, but fails when building with Azure Pipelines.

Environment

OS: Windows 10
.NET Framework: 4.6.1
MSBuild: v16 (VS 2019 Enterprise v16.4.3)
Platform: x86 and AnyCPU

The text was updated successfully, but these errors were encountered:

Hello Cheena. Many thanks for your ping. Unfortunately there’s been no significant progress on this as of yet, but I’ll do my best to have a resolution in place by the end of next week.

Читать:

Как найти эпсилон в физике

@cheenamalhotra I briefly looked at this, and your build is for some reason picking up the program.cs that we inject by custom targets into netcoreapp from Microsoft.NET.Test.Sdk but not into net4.

I tried to repro using a similar project and cannot get it to fail. BUT if I add the compile item into my project I see the same failure.

This looks like a build problem and not like vstest problem but I would be interested in seeing why this happens. I see that you are providing a custom output path so possibly the results of subsequent builds are mixed in a way that causes this issue.

Please provide a diagnostic build log or binlog.

I’d also like to highlight, this does not happen when building locally in Developer Command Prompt but only with Azure Pipeline Jobs, that too intermittently. I’ve also tested locally in the same Agent machine where the build occurs from pipeline, but could not reproduce anytime.

That is why it’s so annoying!

Could you also try to build your repro project from Azure Pipelines and confirm your project builds properly? I’ve also captured binlog for it before and investigated, but it just doesn’t make sense why would this go to .NET Core side of things!

I’m captured binlog in devops job again, it’s intermittent so took multiple runs.
binlog.zip

@cheenamalhotra could you hit me with a bin log from successful run please?

It looks like this is «stale» for some reason:

And the generate build will enter the tests projects from the XUnitUtilities project. But I am hardly sure about it until comparing it with a working build.

@cheenamalhotra There are some issues with the structure of the build.proj used to structure the repo’s overall build.

Because it runs Restore as part of the main build, instead of as a separate phase, you won’t reliably pick up updated build logic. You should build with dotnet build /restore (or msbuild.exe /restore ) instead, and hook up a new Restore target in build.proj to do the Restore operation. But that won’t be sufficient to fix this problem.

I don’t think that’s the major problem here, though. In build.proj , restore is run separately for netcore and netfx:

Because each restore operation happens for a specific TargetFramework , the generated import file Microsoft.Data.SqlClient.Tests.csproj.nuget.g.targets is specific for a given TF. In the failure log you uploaded, that means it includes

Note the explicit include of the netcoreapp2.1 build logic from referenced packages.

What happens is this:

The core restore happens, and *.nuget.g.targets is written (for netcoreapp ).
The full restore happens
a. Because you don’t specify ExcludeRestorePackageImports=false when doing restore, MSBuild follows the import laid down by step 1, and loads the netcoreapp flavor of *.nuget.g.targets into projects into its XML cache.
b. *.nuget.g.targets is overwritten with a desktop framework/netfx version
The core build happens and is happy (because the import comes from 2a and is netcore).
The netfx build happens and is unhappy (because the import comes from 2a and is netcore).

The best fix for this would be to rely on standard multitargeting for the projects—specifying TargetFrameworks (plural) with the appropriate set for the current build environment.

(By the way, you should consider moving to solution-based restore for performance and consistency.)