It seems like everything has broken overnight at the same time... sigh.
In a desperate attempt to fix other random problems I need to make a build of our large project only to find that our teamcity build agents can no longer do their job. The error message is below:
[CallTarget] Version (1s)
[Version] MSBuild.ExtensionPack.Framework.AssemblyInfo (1s)
[MSBuild.ExtensionPack.Framework.AssemblyInfo] I:\BuildAgent-DEVTC1\work\e7d35660eba50bd6\build.proj(150, 3): error MSB4018: The "MSBuild.ExtensionPack.Framework.AssemblyInfo" task failed unexpectedly.
System.ArgumentNullException: Value cannot be null.
Parameter name: input
at System.Text.RegularExpressions.Regex.Matches(String input)
at MSBuild.ExtensionPack.Framework.Version.ParseVersion(String version) in D:\Projects\MSBuildExtensionPack\Releases\4.0.3.0\Main\Framework\Framework\AssemblyInfo\Version.cs:line 51
at MSBuild.ExtensionPack.Framework.AssemblyInfo.Execute() in D:\Projects\MSBuildExtensionPack\Releases\4.0.3.0\Main\Framework\Framework\AssemblyInfo\AssemblyInfo.cs:line 1011
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
The proj definition for the Version target is the following where #VersionDefinition is an "inlcude" for all AssemblyInfo.cs files:
<Target Name="Version">
<MSBuild.ExtensionPack.Framework.AssemblyInfo
AssemblyInfoFiles="#(VersionDefinition)"
AssemblyVersion="$(BUILD_NUMBER)"
AssemblyCopyright="Copywrite info here"
AssemblyCompany="Company info here"
AssemblyFileVersion="$(BUILD_NUMBER)"/>
</Target>
I can see that teamcity is correctly passing in BUILD_NUMBER with a valid value too.
Any ideas?
I'm open to suggestions that don't rely on the extension pack to set AssemblyInfo.cs numbers. I have looked into the TeamCity Assembly Info Patcher but I wasn't sure what "standard locations" was referring to in its description.
On a side note, have there been any updates recently to windows or .NET that could have broken everything...everywhere? I have recently had numerous third party libraries start to fail, almost simultaneously.
Thanks
UPDATE
The logs for recent successful build do not even show the Version target being called... which is odd given that that's the only place the correct build number is set and the build created files with the correct number applied.
So I installed a newer version of the ExtensionPack (4.0.13.0) on to the build clients and got a slightly clearer error message that told me which file was at fault.
Examining the AssemblyInfo.cs file mentioned the AssemblyVersion and AssemblyFileVersion values were missing. Adding these solved the issue.
The interesting part here is that the suspect project has not been touched for years so the values had never have been set. A quick scan through our git logs confirms this. Ultimately I'm not sure what triggered this to become a problem but it is no longer.
Related
I am trying to integrate Fitness with Visual Studio 2022. Have .NET 6.0 installed. Following the instructions given in this link. However, every time I run the Test it throws the error
Could not complete testing: fitnesse.slim.SlimError: Error SLiM server died before Header Message could be read. Unable to start test system 'slim': fitnesse.slim.SlimError: Error SLiM server died before Header Message could be read.
Looks like I am missing something very basic about Slim. Please let me know the resolution for this.
I was able to resolve this. The Target Framework RunnerW was pointing to was incorrect. It was pointing to Dotnet4.8. I modified this. But, and included into the fitsharp solution. Then, building solution from Visual Studio kept failing. Identified that this needed updating the Nuget package. Updating kept skipping every time stating the package was already installed. Was unable to build because of these reasons. Was finally able to have breakthrough when I built the solution from cli. Running the Test after this was successful.
I'm trying to build and run the Hello World sample at the tutorial page at R.NET. When I force the program to run in x86 mode, it seems to do OK. However, when I run in x64, it stops very early on with the message, "[program] exited with code-1073740791"
I've installed the latest version of R at The R Project and have ran the troubleshooting steps. The output I've gotten from the troubleshooting program is:
Is this process 64 bits? True
Info: caller provided rPath=null, rHome=null Info: R.NET looked for preset R_HOME env. var. Found null
Info: Found Windows registry key RDotNet.NativeLibrary.WindowsRegistryKey
Info: Found Windows registry key RDotNet.NativeLibrary.WindowsRegistryKey
Info: Found sub-key InstallPath under RDotNet.NativeLibrary.WindowsRegistryKey
Info: InstallPath value of key RDotNet.NativeLibrary.WindowsRegistryKey: C:\Program Files\R\R-4.0.3
Info: R.NET looked for platform-specific way (e.g. win registry). Found C:\Program Files\R\R-4.0.3
Info: R.NET trying to find rPath based on rHome; Deduced C:\Program Files\R\R-4.0.3\bin\x64
C:...\bin\x64\Debug\net5.0\ConsoleNet5R.exe
(process 33500) exited with code -1073740791.
I have verified that there IS a file R.dll where it deduced it should be, "C:\Program Files\R\R-4.0.3\bin\x64". When I step through using my decompiler, it appears that it gets choked up at what is showing up for me as line 400 in REngine.cs, under the function "Initialize" at this.GetFunction<setup_Rmainloop>()(); It doesn't appear to throw an exception, it just stops. I'll be honest--I'm not sure what this line is supposed to be doing...
Any ideas what is going on? I can run in x86 mode if I have to, but I would like to use x64 if possible.
This issue has been reported for a while..
I experienced the same with R-4.0.3 to R-4.0.5.
There is not such issue for R-4.0.2 and former versions (4.0.1, 4.0.0, 3.6, 3.5)
I've done an analysis of this and tracked findings in one of the RDotNet GitHub issues where this was raised (https://github.com/rdotnet/rdotnet/issues/139#issuecomment-898699993).
This appears to be related to the Control Flow Guard security feature enabled in Windows 10. This doesn't happen in the R programs themselves because they are compiled using a different compiler (gcc via mingw) than Microsoft's. However, the CFG feature is enabled for .NET binaries and there is something (sorry, I don't know the actual underlying root cause) in a change within R 4.0.3 in setjmp/longjmp calls that is causing the crash (see: https://github.com/wch/r-source/blob/trunk/src/gnuwin32/fixed/h/psignal.h#L44-L51).
Although you would actually be disabling a security feature, I have had some luck for now in modifying my program after it is compiled (you can set this as a post-build event). You will need to run something like: link /EDIT /GUARD:NO <yourapp>.exe, which disables CFG.
Thanks to https://github.com/dotnet/runtime/issues/11899#issuecomment-502195325 for providing the instructions needed for this workaround, and https://www.trendmicro.com/en_us/research/16/j/control-flow-guard-improvements-windows-10-anniversary-update.html for providing the amazing analysis of CFG that led to an understanding of what was going on.
Built this game through Unity, and managed to compile through xCode once before. Without any apparent changes, however, this error message turns up. I don't understand where to start looking for a fix, but maybe someone else have a clue? I've seen similar looking errors through searches, though the fixes seem arbitrary compared to mine.
Anyone able to shed some light? Thank you!!
0 0x1034de0e7 __assert_rtn + 144
1 0x10351350c archive::File<arm>::makeObjectFileForMember(archive::File<arm>::Entry const*) const + 1142
2 0x103512c9a archive::File<arm>::forEachAtom(ld::File::AtomHandler&) const + 416
3 0x10352a6a1 ld::tool::InputFiles::forEachInitialAtom(ld::File::AtomHandler&, ld::Internal&) + 465
4 0x10353490e ld::tool::Resolver::resolve() + 48
5 0x1034dec47 main + 679
A linker snapshot was created at:
/tmp/wingOstar-2014-09-26-171939.ld-snapshot
ld: Assertion failed: (memberIndex != 0), function makeObjectFileForMember, file /SourceCache/ld64/ld64-236.4/src/ld/parsers/archive_file.cpp, line 355.
clang: error: linker command failed with exit code 1 (use -v to see invocation)
This seems like the kid of error the Xcode developers hope you never actually see...
The part of that message that is likely most useful for searching against will be the ld: Assertion failed: (memberIndex != 0), since that is the root of the error rather than supporting information.
I probably found the same few sources you did, but they indicated that this is caused by corruption in one of the resources Xcode is trying to link your program against, rather than something immediately caused by your own code. A file becoming corrupted by some external action would explain how this can happen despite no obvious changes in your program source.
So the obvious suggestion for fixing this would be to repair the corruption by making sure whatever is causing it gets recompiled. The first thing to do is to completely clean your project so that no older precompiled files are used and all of your own code is rebuilt. Since your error mentions a source cache, follow the recommendation here to wipe all caches, not just those cleared by the Product->Clean option.
The error message also gives a suggestion to use the -v flag to see what ld is actually doing, which may help you narrow down which object files could be corrupt (by showing you which ones are actually used). To add the flag, go to Build Settings in your project's settings, go down to Linking->Other linker flags, and add -v to those. Once you've rebuilt the project, look at the Build messages in the Report Navigator panel, and expand the linker messages for a full list of linked objects. If any of these options refer to libraries you provided, consider deleting and rebuilding them, before cleaning and rebuilding your project again.
I have an Azure project in TFS that used to work well.
I've just get the latest version and rebuilt the project and now I get the following version:
Error 131 The XML specification is not valid: The 'schemaVersion' attribute is invalid - The value '2013-10.2.2' is invalid according to its datatype 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition:SchemaVersion' - The Enumeration constraint failed. D:\TFS_BOIRA\PROPPOSV3\BACKEND\ServiceLayer.Azure1\ServiceDefinition.csdef 2 125 ServiceLayer.Azure1
The same configuration in another computer works well.
I have checked the version of Azure Tools of both computers and we have different versions.
In my computer (Where I get the error) I have azure tools 2.3, whereas in the other computer where it works well the version is 2.2.
May it be a problem of azure tools versions?
When I add the role to the Azure cloud project, the assemblies:
Microsoft.WindowsAzure.Diagnostics
Microsoft.WindowsAzure.ServiceRuntime
are updated to version 2.3.0.0, and I need them in version 2.2.0.0.
Do I have to reinstall my azure tools to the version 2.2?
Thanks
In addition to Ingrid's answer, you need to get the latest schema version within the ServiceDefinition (.csdef) and ServiceConfiguration (.cscfg) files, and it is not good enough to just change the raw version value (e.g. 2.3), you also need the new version date:
2.3: schemaVersion="2014-01.2.3"
2.4: schemaVersion="2014-06.2.4"
<ServiceConfiguration serviceName="MyCoolCloudProjectName" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="4" osVersion="*" schemaVersion="2014-06.2.4">
<ServiceDefinition name="MyCoolCloudProjectName" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
You need to keep this in sync if you are working on two different machines. Either bring both up to 2.3 or revert. Keep in mind that as part of upgrading it may have changed config files which you haven't checked in yet.
Finally what it worked for me was reverting the version of Azure Tools, as #Steve Newton has said.
How to revert the version it tis explained here:
http://social.msdn.microsoft.com/Forums/en-US/8701b03a-804f-4953-9ea0-01064aa4dc16/downgrade-from-18-tools-to-17?forum=azuretfs.
What I did was:
1.Modify the .ccproj file: the following two tags changing 2.3 to 2.2.
< ProductVersion>2.2< /ProductVersion>
< CloudExtensionsDir Condition=" '$(CloudExtensionsDir)' == '' ">$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Windows Azure Tools\2.2\< /CloudExtensionsDir>
2.Open the files ServiceConfiguration.Cloud.cscfg and ServiceDefinition.csdef and change the version there.
I have the same kind of error
[my config: java/eclipse or jenkins/azure eclipseplugin/azure sdk]
ServiceDefinition.csdef (2, 128): Error CloudServices051 : The XML specification is not valid: The 'schemaVersion' attribute is invalid - The value '2014-06.2.4' is invalid according to its datatype 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition:SchemaVersion' - The Enumeration constraint failed.
I had no error on my workstation using Eclipse or console but I got this error on my Jenkins instance. It was maybe a difference between SDK. I updated both ( jenkins and my workstation) with the same SDK version but I keep this error... :(
The only workaround I found to have a success build was to remove this attribute from ServiceDefinition.csdef root element.
<ServiceDefinition xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" name="AzureDeploymentProject">
In my build I keep the following warning but the package is build with success.
ServiceDefinition.csdef: Warning CloudServices040 : The 'schemaVersion' attribute is unspecified. Please set the attribute to avoid this warning.
Our company was glad to see the release of the C# plugins for sonar, and jumped on the first release. However, we seem to be running into an execption reported by the ProjectLinkSensor. Here's what we did:
On a Windows XP machine, we installed the following:
Windows 7 Development kit (to get to FxCop)
Fxcop 10.0
Gallio
Sonar 2.9 RC1 (running the Derby database)
Maven
2.2.1
Then we checked out the solution, and placed the following pom.xml in the directory where the sln file is:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.rolfje</groupId>
<artifactId>SomeSilverlightProject</artifactId>
<version>1.0-SNAPSHOT</version>
<name>SomeSilverlightProject</name>
<properties>
<sonar.language>cs</sonar.language>
</properties>
<build>
<sourceDirectory>${basedir}</sourceDirectory>
</build>
</project>
In the home directory of the user that's running the maven build we've placed the following settings.xml:
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<profiles>
<profile>
<id>dotnet</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<sonar.gallio.mode>skip</sonar.gallio.mode>
<sonar.gallio.installDirectory>C:/Program Files/Gallio</sonar.gallio.installDirectory>
<sonar.fxcop.mode>skip</sonar.fxcop.mode>
<sonar.fxcop.installDirectory>D:/Program Files/Microsoft Fxcop 10.0</sonar.fxcop.installDirectory>
<sonar.partcover.mode>skip</sonar.partcover.mode>
<sonar.partcover.installDirectory>C:/Program Files/PartCover/PartCover .NET 4.0</sonar.partcover.installDirectory>
<sonar.gendarme.mode>skip</sonar.gendarme.mode>
<sonar.gendarme.installDirectory>C:/Program Files/gendarme-2.6-bin</sonar.gendarme.installDirectory>
<sonar.gendarme.mode>skip</sonar.gendarme.mode>
<sonar.stylecop.installDirectory>C:/Program Files/Microsoft StyleCop 4.3.2.1</sonar.stylecop.installDirectory>
<sonar.jdbc.url>jdbc:derby://localhost:1527/sonar</sonar.jdbc.url>
<sonar.jdbc.driver>org.apache.derby.jdbc.ClientDriver</sonar.jdbc.driver>
<sonar.jdbc.username>sonar</sonar.jdbc.username>
<sonar.jdbc.password>sonar</sonar.jdbc.password>
<sonar.host.url>http://localhost:9000</sonar.host.url>
</properties>
</profile>
</profiles>
</settings>
Please note that I put "skip" in front of all modules. I did this one by one, hoping that switching off one of these modules would remove the error and I would be able to give you a clearer bug report. However this did not help.
When I go into the project directory (where the sln file is) and I run the following command:
mvn -e clean sonar:sonar
I see that the maven sonar plugin does analysis, fetches settings from the local sonar instance, and generates the expected output files (target/sonar/stylecop-msbuild.xml for instance). However, these reports do not get uploaded to sonar, and I see the following error being reported by maven:
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Can not execute Sonar
Embedded error: org.sonar.plugins.core.sensors.ProjectLinksSensor has unsatisfied dependency: class org.apache.maven.project.MavenProject among unsatisfiable dependencies: [[class org.apache.maven.project.MavenProject]] where org.sonar.batch.bootstrap.ProjectModule#2c507f:135<I<org.sonar.batch.bootstrap.BatchModule#659812:139<I<org.picocontainer.DefaultPicoContainer#eb1882:44<| was the leaf container being asked for dependencies.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Can not execute Sonar
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
Aside from the rather unhelpful error (ProjectModule#2c507f doesn't really tell me much), this looks like a nasty bug, which is causing the sonar upload (at least for me) to not work.
Did anybody else have this issue? What is causing this and why is the error reporting so terrible in this case?
Please note taht I've also reported this as a bug on Jira, because I really think the Sonar/C-Sharp plugin ecosystem is leaving me in the dark here. However, it was put into the "Wont't fix" state without additional information. The Jira bug is here: https://jira.codehaus.org/browse/SONARPLUGINS-1264
I don't know if this will solve your problem, but I noticed that you refer to the C drive in all of your <sonar.*.installDirectory> tags, except for <sonar.fxcop.installDirectory>.
Oh, and you could also try to disable the stylecop module since you've accidentally copy-pasted <sonar.gendarme.mode>skip</sonar.gendarme.mode> in front of that module...
I am one of the main developers of sonar for c#.
I did not seen your jira ticket before. I actually agree with Fabrice, you should have send a mail to the user mailing-list.
About your issue, my first guess is that there is an error with your pom.xml file.
If you use "mvn -e clean sonar:sonar", you need to declare in the pom.xml file the "maven-dotnet-plugin" plugin. The "clean" part will be performed by this plugin.
Also, the correct command line would rather be "mvn clean package sonar:sonar", there will not be any assembly to analyse.
For more information on the maven-dotnet-plugin you can check out the documentation on :
http://maven-dotnet-plugin.appspot.com
You will find a pom example here :
http://maven-dotnet-plugin.appspot.com/configuration.html
Hope it helps