Skip to content
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

Error 0x57: The "version" parameter is not supported\MSBuild #92

Closed
Horcrux7 opened this issue Mar 29, 2018 · 8 comments · Fixed by #93
Closed

Error 0x57: The "version" parameter is not supported\MSBuild #92

Horcrux7 opened this issue Mar 29, 2018 · 8 comments · Fixed by #93
Labels

Comments

@Horcrux7
Copy link

With the new version 2.19 of the plugin on our build system we receive:

:msbuild FAILED
   Task: :msbuild took 1843ms

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':msbuild'.
> java.io.FileNotFoundException: C:\jenkins\workspace\Build-PDFC-ProcessBridge-NET\PDFCProcessBridge.NET\Visual Studio Locator version 2.3.7+gfb01ddad81
  Copyright (C) Microsoft Corporation. All rights reserved.
  
  Error 0x57: The "version" parameter is not supported\MSBuild

.....

Caused by: java.io.FileNotFoundException: C:\jenkins\workspace\Build-PDFC-ProcessBridge-NET\PDFCProcessBridge.NET\Visual Studio Locator version 2.3.7+gfb01ddad81
Copyright (C) Microsoft Corporation. All rights reserved.

Error 0x57: The "version" parameter is not supported\MSBuild
	at com.ullink.MsbuildResolver.findMsbuildByVsWhere(MsbuildResolver.groovy:36)
	at com.ullink.MsbuildResolver$findMsbuildByVsWhere.callStatic(Unknown Source)
	at com.ullink.MsbuildResolver.setupExecutable(MsbuildResolver.groovy:62)
	at com.ullink.IExecutableResolver$setupExecutable$0.call(Unknown Source)
	at com.ullink.Msbuild.getCommandLineArgs(Msbuild.groovy:156)
	at com.ullink.Msbuild_Decorated.getCommandLineArgs(Unknown Source)
	at org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.invokeMethod(BeanDynamicObject.java:479)
	at org.gradle.internal.metaobject.BeanDynamicObject.tryInvokeMethod(BeanDynamicObject.java:191)
	at org.gradle.internal.metaobject.CompositeDynamicObject.tryInvokeMethod(CompositeDynamicObject.java:98)
	at org.gradle.internal.metaobject.MixInClosurePropertiesAsMethodsDynamicObject.tryInvokeMethod(MixInClosurePropertiesAsMethodsDynamicObject.java:30)
	at org.gradle.internal.metaobject.ConfigureDelegate.invokeMethod(ConfigureDelegate.java:80)
	at com.ullink.Msbuild$_build_closure7.doCall(Msbuild.groovy:151)
	at org.gradle.api.internal.ClosureBackedAction.execute(ClosureBackedAction.java:71)
	at org.gradle.util.ConfigureUtil.configureTarget(ConfigureUtil.java:160)
	at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:106)
	at org.gradle.util.ConfigureUtil$1.execute(ConfigureUtil.java:123)
	at org.gradle.api.internal.file.DefaultFileOperations.exec(DefaultFileOperations.java:187)
	at org.gradle.api.internal.project.DefaultProject.exec(DefaultProject.java:1076)
	at org.gradle.api.internal.project.DefaultProject.exec(DefaultProject.java:1071)
	at org.gradle.api.Project$exec$4.call(Unknown Source)
	at com.ullink.Msbuild.build(Msbuild.groovy:150)
	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
	... 41 more
@Horcrux7
Copy link
Author

We can reproduce the same error also with version 2.18 and 2.17. With version 2.16 it work. It is not a regression in the latest version 2.19. Seems that some things in our server build environment is outdated. The question is what?

@ngyukman
Copy link
Contributor

Starting from 2.17 we use vswhere from https://github.com/Microsoft/vswhere in order to work with the latest manifold location

Can you try to see if you can get the path from that tool in your Jenkins server?

@Horcrux7
Copy link
Author

I have try to execute vswhere manually on our build system. It returns only the logo.
If I call it with -legacy then I receive:

vswhere -legacy
Visual Studio Locator version 2.3.7+gfb01ddad81
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: VisualStudio.14.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio 14.0\
installationVersion: 14.0

@ngyukman
Copy link
Contributor

https://github.com/Ullink/gradle-msbuild-plugin/blob/master/src/main/groovy/com/ullink/MsbuildResolver.groovy

Perhaps you have version set in your build.gradle manifold section?
That could be a bug indeed

@Horcrux7
Copy link
Author

Yes, we use the version property because without not all of our old projects builds.

@Horcrux7
Copy link
Author

Horcrux7 commented Mar 29, 2018

Sorry, I have oversee you question because I have hold the browser open.

Can you try to see if you can get the path from that tool in your Jenkins server?

We does not have vswhere on this docker image. I can't find it. I think it exist first since VS 2015.

If you think that VS 2014 is to old to support it in the current version then this is ok. We want modernize our infrastructure. That I evaluate VS 2017. A better error message with a hint to an old plugin version would be nice.

@Horcrux7
Copy link
Author

After looking in your linked source code:

line 34: def msbuildDir = new File(location, 'MSBuild')

I think it is a good idea to check if the directory exists. If the directory does not exists because it is an error message then MsBuild directory will be search from the registry. This should work with older versions.

@ngyukman
Copy link
Contributor

ngyukman commented Apr 28, 2018

I have try to execute vswhere manually on our build system. It returns only the logo.
If I call it with -legacy then I receive:

likely we should add -legacy when invoking vswhere with version <= 14.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants