Ugh....Microsoft have done something.
All our builds that have been kicked off in the last few hours (approx 10:00 GMT) are failing on our "Build Solution step" failing because of the following error (from the logs):
##[error]EXEC(0,0): Error : Error occurred during processing of input file 'XXX.XXX.dll' --> Method not found: 'System.ReadOnlySpan1 Microsoft.IO.Path.GetFileName(System.ReadOnlySpan1<Char>)'.
Does anyone have any ideas on this? Nothing in our codebase has changed.
If you need more information please let me know. Thanks
FYI, this seems to be caused by a recent update to MSBuild (https://github.com/dotnet/msbuild/pull/7680) that has updated the version of System.Memory.
It looks like the obfuscation tool you're using in your build pipeline is built against a previous version of System.Memory and now that the version provided by the MSBuild environment has changed, the obfuscation tool is broken. Most likely requires the obfuscation tool to be updated.
(PS. I'm just relaying the information that others have identified where other tools are having the same issue - see https://github.com/T4MVC/R4MVC/issues/172)
Related
dart2js error with dash_chat
One of our existing applications makes use of dash_chat, which is working on a V2, however, v2 has a fraction of the APIs implemented. The project is somewhat dormant so today we just doing housekeeping and trying to keep the project up-to-date.
I am now getting this error, and sadly I went and updated all packages and we are using FLutter 3 and Dart 2.17 in all our other projects.
Target dart2js failed: Exception: Warning: The 'dart2js' entrypoint script is deprecated, please use 'dart compile js' instead.
So not sure which of the many things I changed is ultimately the cause of this issue, which crops up when trying to build for web.
No relevant issues on the DC repo and google is being very unhelpful on this one, was hoping someone had some insight that would allow me to take the correct steps forward (or back if need be) to get around this.
TIA
I am getting the following error along with a lot of others when trying to compile jobs on DataStage 11.7:
Error when checking composite operator: Subprocess command failed with exit status 256
I did an internet search of all possible solutions. Could not look at dsxchange as the site is down. Looked at all compiler options and they look the same as other projects with successful compilation.
IBM has a solution but it did not work for me:
https://www.ibm.com/support/knowledgecenter/SSZJPZ_11.3.0/com.ibm.swg.im.iis.ds.trouble.ref.doc/topics/transformstage01.html
Any ideas?
There are 165 hits on DSXchange (it is not down).
Can you please verify your operating system and the values of the four environment variables that control your compiler and linker (APT_COMPILER, APT_COMPILEOPT, APT_LINKER and APT_LINKEROPT)? Please also verify the exact version of DataStage that you are running and the exact version of the compiler.
As noted in the Knowledge Center article, this error usually relates to the compiler being incompatible, the incorrect version, or having incorrect options.
I have been having an issue with application packages where there will be days/times where I just get a null exit code and BlobAccessDenied Error for the exact same application package and exact same command line that previously worked and gave a non-null exit code. For instance, today, I've been getting this error for the exact same packages and commands that I ran yesterday. What am I missing? Or is this a bug in the application packages service? (for VM configuration)
Update:
This fix is been released and deployed, this error will no longer exist for the specified case.
Also something I wrote in an hour jsut to test and might come handy apart from good dotnet samples :
https://github.com/Tatsinnit/quick_sample_batchapppkgworking
https://github.com/Azure/azure-batch-samples
Thanks j.B. & Jan
I am using the OpsHub migration tool and have the following error
"OH-SCM-009: Error occurred while sync. Pend Rename failed after {41} attempts. Cannot resolve the Cyclic Rename/Move encountered"
At first i wondered if the error was due to a project not being included in the migration but this doesn't seem to be true as I get the error when trying to migrate all the projects I have.
I am not sure how i can start to debug this. I cannot even see what project has the problem.
Have tried just running a retry but does same issue occurs.
Update for anyone encountering the same issue using the Utility.
This was a special case during Cyclic Rename/Move resolution algorithm that OpsHub Utility supports and implements.
It has been fixed in v1.1.0.001. Hence, newer versions of the utility wont have this issue.
#Buzzby : You can use the newer version to solve your problem.
Thanks.
I am evaluating PostSharp for a new project but cannot seem to get past the following error when I first build the project after changes:
Cannot copy file "C:\SourcePath\Output\Debug\MyApp.vshost.exe to
obj\Debug\Before-PostSharp\MyApp.vshost.exe: the file is locked by
process(es):MYAPP.VSHOST (8064)
The error only occurs in the first build attempt. If I immediately re-build, the error does not occur. I can only guess this is because the project isn't actually being rebuilt the second time.
I've read a few posts in the SharpCrafters forum that indicate this problem existed prior to v2.1 but was reportedly fixed. I am using v2.1.6.14 from NuGet (in VS 2010) and getting this error for every project I reference PostSharp. It is certainly not reasonable to require 2 builds every time, so I'm looking for a possible solution. I'm really pleased with what I've seen thus far but will have to go another direction if that can't be resolved.
UPDATE
Per Gael's request, I generated the diagnostic build log and sent it to him and it looks like he was able to resolve the problem in the latest release (2.1.6.14).
I believe part (or all) of the issue may be due to the fact that the build output for all of my projects is set to a common location (i.e. not the /bin/debug folder under each project). This is because we are using a MEF DirectoryCatalog which will discover Imports and Exports contained in the assemblies located in the output path. The PostSharp.targets file has the vshost.exe file excluded from the copy operation but only when it shares the name of the output assembly. In my case, the vshost.exe file has a different name and was, therefore, not being excluded.
The issue has been re-fixed in PostSharp 2.1.6.15.