Msbuild error msb1001 unknown switch

Godot version:
master — 12482bf

OS/device including version:
Windows 10

Issue description:
Compiling with mono fails with MSBUILD error:

build_godot_tools(["binGodotSharpToolsGodotTools.dll"], ["binGodotSharpApiReleaseGodotSharp.dll", "binGodotSharpApiReleaseGodotSharp.pdb", "binGodotSharpApiReleaseGodotSharp.xml", "binGodotSharpApiReleaseGodotSharpEditor.dll", "binGodotSharpApiReleaseGodotSharpEditor.pdb", "binGodotSharpApiReleaseGodotSharpEditor.xml"])
NuGet path: c:/Program Files/Monobinnuget.bat
MSBuild auto-detection: using msbuild version '15.0' from 'c:Program FilesMonolibmonomsbuild15.0bin'.
WARNING: Error reading msbuild project information, ensure that your input solution or project file is valid. NETCore and UAP projects will be skipped, only packages.config files will be restored.
All packages listed in packages.config are already installed.
MSBuild path: C:Program Files (x86)Microsoft Visual Studio2019CommunityMSBuildCurrentBinMSBuild.exe
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : error MSB1001: Unknown switch.
Switch: /Target=BuildAlwaysCopyToDataDir

For switch syntax, type "MSBuild -help"
scons: *** [binGodotSharpToolsGodotTools.dll] RuntimeError : 'msbuild' exited with error code: 1
Traceback (most recent call last):
  File "C:devgodotmodulesmonobuild_scriptssolution_builder.py", line 150, in run_command
    subprocess.check_call(args, env=env_override)
  File "C:Users<user>AppDataLocalProgramsPythonPython36libsubprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe', 'C:\dev\godot\modules\mono\editor/GodotTools/GodotTools.sln', '/p:Configuration=Release', '/Target=BuildAlwaysCopyToDataDir']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:users<user>appdatalocalprogramspythonpython36libsite-packagessconsSConsAction.py", line 1209, in execute
    result = self.execfunction(target=target, source=rsources, env=env)
  File "C:devgodotmodulesmonobuild_scriptsgodot_tools_build.py", line 21, in build_godot_tools
    build_solution(env, solution_path, build_config, extra_build_args)
  File "C:devgodotmodulesmonobuild_scriptssolution_builder.py", line 214, in build_solution
    run_command(msbuild_path, msbuild_args, env_override=msbuild_env, name='msbuild')
  File "C:devgodotmodulesmonobuild_scriptssolution_builder.py", line 152, in run_command
    raise RuntimeError("'%s' exited with error code: %s" % (name, e.returncode))
RuntimeError: 'msbuild' exited with error code: 1
scons: building terminated because of errors.

Possibly related to 86274b9
Steps to reproduce:
Windows 10
Mono JIT compiler version 6.6.0 (Visual Studio built mono)

pull latest

rm -rf ./bin/*

# Build temporary binary
scons p=windows tools=yes module_mono_enabled=yes mono_glue=no
# Generate glue sources
bingodot.windows.tools.64.mono --generate-mono-glue modules/mono/glue

rm ./bin/*

### Build binaries normally
# Editor
scons p=windows target=release_debug tools=yes module_mono_enabled=yes
# Export templates
scons p=windows target=release_debug tools=no module_mono_enabled=yes
scons p=windows target=release tools=no module_mono_enabled=yes

Also tried scons -c before building

Msbuild error msb1001 unknown switch

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I follow the steps here to enable debugger in MSBUILD for VS2010:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSBuild4.0 key to have debuggerenabled=true

It works on one of my machine but not working on my super machine that running on 64x.

I cannot enable the MsBuild debugging.

the DebuggerEnabled is true in registry.

D:>reg query «HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSBuild4.0»

DefaultToolsVersion REG_SZ 2.0

MSBuildOverrideTasksPath REG_SZ C:WindowsMicrosoft.NETFramework64v4.0.30319

DebuggerEnabled REG_SZ true

but msbuild does not recognize the /debug switch.

Microsoft (R) Build Engine Version 4.0.30319.1

[Microsoft .NET Framework, Version 4.0.30319.1]

Copyright (C) Microsoft Corporation 2007. All rights reserved.

Источник

dotnet commands that do an implicit restore don’t support —interactive flag #9774

Steps to reproduce

Expected behavior

I should be able to pass —interactive to build and have it passed to the implicit restore. This makes scenarios with authenticated feeds annoying as I have to explicitly call restore the first time I build.

Actual behavior

Error (see above). A good workaround is adding the following in a Directory.Build.props

Environment data

dotnet —info output:

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

Another workaround would be dotnet build /p:NuGetInteractive=true

Looking at the PR that introduced this flag, it seems like this case was explicitly called out as something that was not wanted and that the design doc called for it being available only in the restore command.

The code in PR was changed to not allow the —interactive flag to be passed through.

So, this issue seems to be by design. I will let @jainaashish comment on it before closing it though.

I was asked by @nguerrera to open this issue as a «good to consider» in an email thread, so that’s the context on why I opened it.

@nathansoz no worries. I wasn’t aware that this had been considered and rejected until I went and reviewed the PR. Let’s wait to see what @jainaashish has to say regarding the reasons not to do it. In the very list, it gets documented here as well.

I thought the expectation made sense, though I can also see some of the dangers with enabling it. We consider this a very special case, which is why I believe it was explicitly limited to dotnet restore .

@nkolev92 to provide specific details and pointers to spec to capture that discussion to exclude dotnet build or publish for —interactive flag.

It was a shared decision between CLI/MSBuild/NuGet folks. I have the e-mail thread for more details.
We wanted a switch only in the explicit NuGet commands, so we decided not to do a dotnet build —interactive .

From the e-mail thread, redacted for better context:

Personally I’m not leaning either way.

Just from a consumer’s perspective, I think that this falls more into the bucket of «surprising» behavior than not. Intuitively I’d expect to be able to use —interactive and have it passed to whatever implicit commands it invokes. Whether or not that tips the balance for you in terms of adding the functionality is up to you 🙂 There could totally be side-effects here I’m not thinking of.

This confused me again today:

dotnet build
C:Program Filesdotnetsdk2.1.700NuGet.targets(121,5): warning : The plugin credential provider could not acquire credentials. Authentication may require manual action. Consider re-running the command with —interactive for dotnet , /p:NuGetInteractive=»true» for MSBuild or removing the -NonInteractive switch for NuGet [. csproj]

dotnet build —interactive
Microsoft (R) Build Engine version 16.1.76+g14b0a930a7 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1001: Unknown switch.
Switch: —interactive

But maybe my SDKs are just outdated or mismatch somewhere.

Источник

C# Разработка

Блог о создании приложений на платформе .NET Framework

23 октября 2017 г.

Msbuild debugging. Отладка csproj скрипта проекта в Visual Studio.

Представьте ситуацию, что вам необходимо в одном из проектов MyProject.csproj в тело скрипта добавить свой скрипт. Вы разобрались с синтаксисом, написали нужный скрипт-код, вставили в проект, открываете проект и понимаете, что допустили ошибку в написании, при этом, когда пишешь в слепую без отладки и по не знанию можно залипнуть на долгое время.

Но выход есть! Скрипт MsBuild можно отлаживать, ставить breakpoints и смотреть значения переменных. Приведу ссылку на исходную статью Debugging MSBuild script with Visual Studio а тут опишу действия на примере Visual Studio 2015 и некоторые особенности.

Сборку и отладку придется запускать через командную строку msbuild.exe используя опцию /debug, но изначально данная функция не доступна, поэтому при попытке воспользоваться ключом будет ошибка:

D:!BlogDebugFeaturesDebugFeatures>C:WindowsMicrosoft.NETFrameworkv4.0.30319MSBuild.exe /debug DebugFeatures.csproj

Microsoft (R) Build Engine version 4.6.1055.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.

For switch syntax, type «MSBuild /help»

Поэтому потребуется:

Сначала нужно добавить в ветку реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSBuild4.0 значение DebuggerEnabled = true. На компьютере могут стаять две версии .NET Framework — под x64 и x86 поэтому для обоих свои ветки реестра. В статье выше указан путь только к одной ветке, поэтому я приведу текст написанного мной скрипта, который добавит это значение в оба места.

Затем идём в студию, выбираем проект и в контекстном меню выбираем пункт «Unload Project», проект должен стать «Недоступным»:

Далее для запуска отладчика пишем в командной строке «Путьmsbuild.exe» /debug «ПутьMyProject.csproj», запускаем и должны увидеть:

Случаи на работе, когда это пригодилось:

• В одном из проектов писалась встроенная Task для получения ChangeSet номера папки с проектом из TFS и последующая подстановка в версию файла. Тем самым тестировщик каждую сборку имел правильную версию файлов.
  Вы спросили, почему тестировщик этим занимается? Дело в том, что по нормальному этим занимается какой то Build Service, но такого не было и сборка и обновление делалось вручную.
• Имелась утилита собирающая Msbuild скрипт, который наполнялся и создавал ClickOnce приложение. Отладка его сценариев таким образом здорово мне помогло.

Источник

Can’t build on Ubuntu 16.10 #1702

I couldn’t manage a build on my Linux machine. Tools init always fails due to a bad blob url for dotnet.tar.

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

Could you share the full log?

The init-tools log:

dotnet.tar is a blob storage error response and not an archive:

Also, the CI may be caching the tools, that’s why it is passing. It gave me a false outlook on the actual state of the build.

https://dotnetcli.blob.core.windows.net/dotnet/Sdk/1.0.0-preview3-003686/dotnet-dev-ubuntu.16.10-x64.1.0.0-preview3-003686.tar.gz — this seems to be missing now. Though the corresponding copy for OSX does exist. 1.0.0-rc4* is available now. Maybe we can move to that now. Hopefully it shouldn’t affect any other builds! @rainersigwald ?

I don’t think we can move to latest, due to the project.json/MSBuild switchover and some other factors. I hoped we could move to the released version of preview3, 004056, but it is post-MSBuild-switchover and failed during our restore step.

@blackdwarf Is there a build of cli between preview3-003686 (our current, evidently deleted) and preview3-004056 (the first? MSBuild-only build) that’s still available for all OSes? Is there a way for me to tell that on my own?

The error I get on moving to a more recent build is:

@rainersigwald 3686 is alive and well. CLI didn’t, and still doesn’t, produce Ubuntu 16.10 builds thus far [closest is 16.04]. These builds will be coming soon [by 1.0.0 RTM I hope].

So I can hack my way to a build by tricking the build into thinking that I have 16.04 instead of 16.10?

Seems to be working so far. Thanks @piotrpMSFT for the insight.

haha

The patch simply is:

I got a failure for a project named Dependency . I assume that this is a sample project and that MSBuild itself has been compiled. The failure was due to non-support for 16.10 in the project file.

Using a similar patch on cibuild.sh got me as a far as I needed. @radical How do I revert the switch to mcs and use csc instead? I am using mono master which bundles a working csc.

@borgdylan Use the xplat-master branch for working with mono/master. That uses mono’s bundled csc.

Will the Sdks/NuGet targets ever be integrated into MSBuild for mono or will the CLI have to add a way to use the mono version of MSBuild when it exists on the machine?

Eventually, projects using SDKs will work out of the box with msbuild/mono.

I managed to build by symlinking the Sdks folder. I couldn’t use nuget pack support however.

Related to this i think: #1396

Initialization has been overhauled in #2868. I’m going to close this—if anyone is still seeing failures building on Ubuntu, please open a new issue.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

dotnet test -parallel N #631

From @lukasz-pyrzyk on March 17, 2017 14:39

How to disable parallel run for xunit tests?

I found similar issues (#1447, #401), but they look out of date. There is no `-diagnostics« flag.

Should I use -s and create some configuration file?

Steps to reproduce

dotnet test Project.csproj -parallel None
or
dotnet test Project.csproj -parallel none

Expected behavior

Disable parallel execution of the tests

Actual behavior

Environment data

Copied from original issue: dotnet/cli#6059

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

In the new test platform, it is possible to pass args to adapters using the dotnet test — xunit.someconfig=somevalue syntax. I think you can use parallelizeAssembly and parallelizeTestCollections options in xunit.runner.json (https://xunit.github.io/docs/configuring-with-json.html). A sample project with xunit.runner.json is available here: https://github.com/Reactive-Extensions/Rx.NET/blob/develop/Ix.NET/Source/Tests/Tests.csproj.

Created xunit/xunit#1169 to discuss if this is an interesting feature for xunit adapter to support.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Представьте ситуацию, что вам необходимо в одном из проектов MyProject.csproj
в тело скрипта добавить свой скрипт. Вы разобрались с синтаксисом,
написали нужный скрипт-код, вставили в проект, открываете проект и
понимаете, что допустили ошибку в написании, при этом, когда пишешь в
слепую без отладки и по не знанию можно залипнуть на долгое время.

Но выход есть! Скрипт MsBuild можно отлаживать, ставить breakpoints и смотреть значения переменных. Приведу ссылку на исходную статью Debugging MSBuild script with Visual Studio а тут опишу действия на примере Visual Studio 2015 и некоторые особенности.

Сборку и отладку придется запускать через командную строку msbuild.exe используя опцию /debug, но изначально данная функция не доступна, поэтому при попытке воспользоваться ключом будет ошибка:

D:!BlogDebugFeaturesDebugFeatures>C:WindowsMicrosoft.NETFrameworkv4.0.30319MSBuild.exe /debug DebugFeatures.csproj

Microsoft (R) Build Engine version 4.6.1055.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : error MSB1001: Unknown switch.
Switch: /debug

For switch syntax, type «MSBuild /help»

Поэтому потребуется:

• Сначала нужно добавить в ветку реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSBuild4.0 значение DebuggerEnabled = true. На компьютере могут стаять две версии .NET Framework —
  под x64 и x86 поэтому для обоих свои ветки реестра. В статье выше
  указан путь только к одной ветке, поэтому я приведу текст написанного
  мной скрипта, который добавит это значение в оба места.

  SET FrameworkDir=%windir%Microsoft.NETFramework
  SET FrameworkDir64=%windir%Microsoft.NETFramework64
   
  SET Cmd32Exe=%windir%System32cmd.exe
  SET Cmd64Exe=%windir%SysWOW64cmd64.exe
   
  IF EXIST %FrameworkDir% (
   start %Cmd32Exe% /c "reg add "HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSBuild4.0" /v DebuggerEnabled /d true"
  ) 
   
  IF EXIST %FrameworkDir64% (
   start %Cmd64Exe% /c "reg add "HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftMSBuild4.0" /v DebuggerEnabled /d true"
  )
  
  Для запуска скопируйте в блокнот, сохраните как AnyName.bat, затем запустите.
  

• Затем идём в студию, выбираем проект и в контекстном меню выбираем пункт «Unload Project», проект должен стать «Недоступным»:

  

• Далее для запуска отладчика пишем в командной строке «Путьmsbuild.exe» /debug «ПутьMyProject.csproj», запускаем и должны увидеть:

  

• Стоит так же учитывать номер Target Framework вашего проекта и указывать верную директорию C:WindowsMicrosoft.NETFrameworkXXXXXXXXmsbuild.exe, иначе будьте готовы к тому, что в студии всё будет собираться, а из командной строки нет. Если версия Framework понятна, то советую сначала убедиться, что в студии и через найденный msbuild.exe ошибок не возникает при сборке.
• В диалоговом окне выбора отладчика выбираем либо новый экземпляр студии, либо уже запущенный, и вуалям! Можем использовать F10 и breakpoints:

  

Случаи на работе, когда это пригодилось:

• В одном из проектов писалась встроенная Task для получения ChangeSet номера папки с проектом из TFS и последующая подстановка в версию файла. Тем самым тестировщик каждую сборку имел правильную версию файлов.
  Вы спросили, почему тестировщик этим занимается? Дело в том, что по нормальному этим занимается какой то Build Service, но такого не было и сборка и обновление делалось вручную.
• Имелась утилита собирающая Msbuild скрипт, который наполнялся и создавал ClickOnce приложение. Отладка его сценариев таким образом здорово мне помогло.