I've installed Nuget package "Unmanaged Exports (dllExport for .NET). This works fine using MS Visual Studio 2010.
Using MSBuild (Windows SDK v7.1) I get an error Index (zero based) must be greater than or equal to zero and less than the size of the argument list.
Any idea how this can be solved?
Partial MSBuild output:
MethodDeclarationParserAction: Found method: HSAdapter.HSAdapter..method public hidebysig static void 'CreateHSAdapterInstance'([out] class 'HSAdapter'.'IHSAdapter'& marshal( interface ) 'instance') cil managed
MethodPropertiesParserAction: Removing RGiesecke.DllExport.DllExportAttribute from HSAdapter.HSAdapter.CreateHSAdapterInstance
DeleteExportAttributeParserAction: Adding .vtentry:0 .export:CreateHSAdapterInstance
Parse IL: Deleting unused reference to RGiesecke.DllExport.Metadata.
Parse IL: Parsing 1676 lines of IL took 51 ms.
D:\HS4\packages\UnmanagedExports.1.2.4.23262\tools\RGiesecke.DllExport.targets(42,5): error : Index (zero based) must be greater than or equal to zero and less than the size of the argument list.
at System.Text.StringBuilder.AppendFormat(IFormatProvider provider, String format, Object[] args)
at System.String.Format(IFormatProvider provider, String format, Object[] args)
at RGiesecke.DllExport.DllExportNotifier.Notify(Int32 severity, String code, String fileName, Nullable`1 startPosition, Nullable`1 endPosition, String message, Object[] values) in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\DllExportNotifier.cs:line 135
at RGiesecke.DllExport.DllExportNotifier.Notify(Int32 severity, String code, String message, Object[] values) in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\DllExportNotifier.cs:line 119
at RGiesecke.DllExport.Parsing.DllExportNotifierWrapper.Notify(Int32 severity, String code, String message, Object[] values) in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\Parsing\DllExportNotifierWrapper.cs:line 41
at RGiesecke.DllExport.Parsing.IlAsm.RunLibTool(CpuPlatform cpu, String fileName, String directory) in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\Parsing\ILAsm.cs:line 212
at RGiesecke.DllExport.Parsing.IlAsm.RunCore(CpuPlatform cpu, String fileName, String ressourceParam, String ilSuffix) in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\Parsing\ILAsm.cs:line 186
at RGiesecke.DllExport.Parsing.IlAsm.Run(String outputFile, String ilSuffix, CpuPlatform cpu) in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\Parsing\ILAsm.cs:line 123
at RGiesecke.DllExport.Parsing.IlAsm.ReassembleFile(String outputFile, String ilSuffix, CpuPlatform cpu) in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\Parsing\ILAsm.cs:line 75
at RGiesecke.DllExport.DllExportWeaver.RunIlAsm(IlAsm ilAsm) in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\DllExportWeaver.cs:line 151
at RGiesecke.DllExport.DllExportWeaver.Run() in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport\DllExportWeaver.cs:line 81
at RGiesecke.DllExport.MSBuild.ExportTaskImplementation`1.Execute() in d:\Work\Libraries\RGiesecke.DllExport\RGiesecke.DllExport.MSBuild\ExportTaskImplementation.cs:line 243
Done Building Project "D:\HS4\HSAdapter\HSAdapter.csproj" (default targets) -- FAILED.
I've just run into the same problem. The RGiesecke.DllExport.targets file references $(DevEnvDir), which won't be defined in the environment you're running msbuild in (but will be from within Visual Studio). I took the quick and dirty approach of adding a system-wide environment variable on the build server (set to "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\") to work around it, as I was in a hurry.
Related
I am creating a test case in Robot framework that checks the memory usage of an application and does some further actions. I am running a keyword that executes a command on command line and returns the output.
I am using that keyword to run the command wmic process where name=\"${executableName}\" get WorkingSetSize
If we run this command on command prompt we get an output like
WorkingSetSize
353242342
I am executing this command in robot framework using a keyword but I want to modify the output such that I can just store the number in the variable without the "WorkingSetSize" or newline found in my output. How should I approach this?
If the string contains space in between string and Number, then try this
${String and number} hello 123
${number only} Evaluate "${String and number}".split(" ")[1]
Same way you can use any separator in the split function.
This question already has answers here:
Blank space after file extension -> weird FileInfo behaviour
(3 answers)
Closed 7 years ago.
I search files and return FileInfo as IEnumerable. I set a breakpoint in the Select and see the filename passed in is e:\mp3\MP3_Amazon\Orchestra della Scala di Milano, Tullio Serafin,Herbert von Karajan, Maria \Maria Callas, Vol 4\01-15- Madama Butterfly Un bel dì, vedremo.mp3
When I loop through the IEnumerable and try to open the file as Stream I get an error System.IO.DirectoryNotFoundException with the file. The FullName member of the FileInfo misses the space that ends the part of the path Orchestra della Scala...
The path was created by Amazon's MP3 downloader (Amazon Music).
I now wonder if and how it's possible to access the file programatically.
Why is the path split in it's parts and each part stripped from trailing spaces at all whe the FileInfo class is created?
Dim Dir As IEnumerable(Of FileInfo) =
From datei In Directory.EnumerateFiles("E:\MP3\mp3_amazon", "*.*", SearchOption.AllDirectories).Where(
Function(dateiname)
Return dateiname.IndexOf("butter", StringComparison.CurrentCultureIgnoreCase) > -1
End Function
).Select(Of FileInfo)(
Function(dateiname)
Return New FileInfo(dateiname)
End Function
)
Duplicate of this question.
Summary: Windows API doesn't support it, so you have to detect this issue in code and work around it. Using the file's short name (8.3) may work.
I am trying to restore backup file locally using command prompt as below:
Raven.Server.exe -src E:\OTUmbraco\OTWDatabases\UAT_RavenDB -dest E:\OTUmbraco\OTWDatabases\DB\RavenDB -restore
And I am getting error as below:
Esent Restore: Failure! Could not restore database!
Microsoft.Isam.Esent.Interop.EsentBadLogVersionException: Version of log file is not compatible with Jet version
at Microsoft.Isam.Esent.Interop.Api.Check(Int32 err)
at Microsoft.Isam.Esent.Interop.Api.JetRestoreInstance(JET_INSTANCE instance, String source, String destination, JET_PFNSTATUS statusCallback)
at Raven.Storage.Esent.Backup.RestoreOperation.Execute()
Microsoft.Isam.Esent.Interop.EsentBadLogVersionException: Version of log file is not compatible with Jet version
at Microsoft.Isam.Esent.Interop.Api.Check(Int32 err)
at Microsoft.Isam.Esent.Interop.Api.JetRestoreInstance(JET_INSTANCE instance, String source, String destination, JET_PFNSTATUS statusCallback)
at Raven.Storage.Esent.Backup.RestoreOperation.Execute()
at Raven.Storage.Esent.TransactionalStorage.Restore(String backupLocation, String databaseLocation, Action`1 output, Boolean defrag)
at Raven.Database.DocumentDatabase.Restore(RavenConfiguration configuration, String backupLocation, String databaseLocation, Action`1 output, Boolean defrag)
at Raven.Server.Program.RunRestoreOperation(String backupLocation, String databaseLocation, Boolean defrag)
Can any one help me to solve this error.
Thanks in advance.
You cannot go back in the windows version when using RavenDB with Esent.
I have a console application that takes input command line arguments. I have to schedule this task on Windows 8 using Win32.TaskScheduler. The problem is whenever my command line arguments length exceeds 450 characters, i get a warning like this :
Task registered task "TaskName" , but not all specified triggers will start the task. User Action: Ensure all the task triggers are valid as configured. Additional Data: Error Value: 2147944183.
And the task does not run eventually at the run time.
Is there any limit on command line arguments' length?
I encountered a similar issue with scheduled tasks and command line arguments that exceeded 260 characters. We got the same useless error that you did.
Eventually we had to change the command line arguments so they were smaller (length of file paths in argument list)
We had this issue on Windows Server 2012 R2 64 bit, I'm not sure if the bitness has anything to do with it...
My code copies files from ftp (using text transfer mode) to local disk and then trys to process them.
All files contain only text and values are seperated using new line. Sometimes files are moved to this ftp using binary transfer mode and looks like this will mess up line-ends.
Using hex editor, I compared line ends depending the transfer mode used to send files to ftp:
using text mode: file endings are 0D 0A
using binary mode: file endings are 0D 0D 0A
Is it possible to modify my code so it could read files in both cases?
Code from job that illustrates my problem and shows how i'm reading file:
(here i use same file, that contains 14 rows of data)
int i;
container con;
container files = ["c:\\temp\\axa_keio\\ascii.txt", "c:\\temp\\axa_keio\\binary.txt"];
boolean purchLineFirstRow;
IO inFile;
;
for(i=1; i<=conlen(files); i++)
{
inFile = new AsciiIO(conpeek(files,i), "R");
inFile.inFieldDelimiter('\n');
con = inFile.read();
info(int2str(conlen(con)));
}
Files come from Unix system to Windows sytem.
Not sure but maybe the question could be: "Which inFieldDelimiter values should i use to read both Unix and Windows line ends?"
Use inRecordDelimiter:
inFile.inRecordDelimiter('\n');
instead of:
inFile.inFieldDelimiter('\n');
There may still be a dangling CR on the last field, you may wish remove this:
strRem(conpeek(con, conlen(con)), '\r')
See also: http://en.wikipedia.org/wiki/Line_endings