When I construct a new DirectoryInfo using a network path like this:
using Delimon.Win32.IO;
DirectoryInfo di = new DirectoryInfo(#"\\a\path\to\a\place\you\are\not\allowed\to\know")
I know the path is correct since it opens in my browser when I copy paste. But I am getting an error:
"System.OverflowException: Arithmetic operation resulted in an overflow."
This is all the call stack info I can give.
System.OverflowException: Arithmetic operation resulted in an overflow.
at Delimon.Win32.IO.Helpers.GetFileInformation(String path)
at Delimon.Win32.IO.FileSystemInfo.Refresh()
at Delimon.Win32.IO.DirectoryInfo..ctor(String dir)
The path is 67 characters long. So its not a long path.
I can't find any documentation on System.OverflowException resulting from the construction of DirectoryInfo objects.
Any help?
I was getting this exact error just now
System.OverflowException: 'Arithmetic operation resulted in an overflow.'
and managed to isolate the cause.
The following line was giving the error:
string[] files = Delimon.Win32.IO.Directory.GetFiles(#"d:\temp");
This line is from an old app that I'm rewriting. Knowing that it works in the old version, but not in the new version, I've removed everything and everything in the new version and was left with an empty form. I still got the error.
Then I created a new empty project and tried the code in it, and it worked. So even though I removed everything in my new app, I still get the error. This suggests there's something wrong with the settings. So I started comparing project files.
In the *.csproj file, there was this line:
<Prefer32Bit>false</Prefer32Bit>
and it was not in the old app nor in the new project.
It seems that when a new project is created, "Prefer 32-bit" (Project -> Properties -> Build -> General) is checked by default, but in my new app, this was not checked. I don't remember unchecking it myself, so I don't know how it got unchecked. Once I checked it, I no longer get the error.
I was using Delimon.Win32.IO.DirectoryInfo which is apparently an old, un-maintained code base. I should have been using System.IO.DirectoryInfo
Related
LinqPad is my goto REPL and there isn't much I throw at it that it cant handle.
However I cannot for the life of me get CefSharp (specifically OffScreen) to run.
I'm constantly met with either of the below errors
Could not load file or assembly 'CefSharp.Core.Runtime, Version=95.7.141.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138' or one of its dependencies. The system cannot find the file specified.
BadImageFormatException: Could not load file or assembly 'CefSharp.Core.Runtime, Version=95.7.141.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138'. An attempt was made to load a program with an incorrect format.
I have tried
LP5/6 32 and 64 bit
Adding Cefsharp via nuget
Referencing .dll's manually from the file system
Referencing x86 or x64 .dll's
Copying .dll's into assembly search paths
Adding nuget paths to Environment path
And what seems like every combination of the above.
I don't understand the assembly resolution process that Visual Studio uses with the nuget package, but whatever it does I would like to at least simulate in Linqpad so I can avoid the VS ceremony when testing something simple.
I assume that manually referencing the correct .dll's and maybe setting a path somewhere should be sufficient, but I'm ideas=>EOF.
Can CefSharp be run outside of VS / MSBuild ?
It doesn't work because of the shadow-copying that LinqPad is using. Here is a hack to make your problem go away (spoiler alert: not really, read on):
For LinqPad v5
Copy all CefSharp libraries to a separate folder (don't forget cef.redist).
In LinqPad Preferences dialog (Advanced/Execution), set Do not shadow assembly references to True, restart LinqPad.
Write your code in the LinqPad query.
Reference CefSharp libraries from the folder you've set up on step 1.
Run the query.
For previous LinqPad (earlier than v5)
Write your code in the LinqPad query.
Reference CefSharp libraries, so you get an exception from your question
Find a LinqPad working directory (usually something like C:\Users\<user>\AppData\Local\Temp\LINQPad5\_yyigmhzg).
Copy all CefSharp libraries to this folder (don't forget cef.redist).
In LinqPad, click Ctrl + Shift + F5; this will reset the query state.
Rerun the query.
Now all the referenced libraries should load. But you will likely face more problems after that.
I couldn't make CefSharp.MinimalExample work. LinqPad kept crashing for me with the cryptic message Query ended because an uncatchable exception was thrown and a crashdump.
Although I am not sure if you will make CefSharp work as intended under LinqPad, maybe this can get you a bit further.
Found the answer with motivation from #Sasha's post and #amaitland's note about BadImageFormatException's being more than just incorrect architectures.
The below is all in reference to LP6 and CefSharp.Offscreen.NetCore. I have not pushed the efforts into LP5 but the process should be similar.
After some trial and error I narrowed down all of the necessary dependencies and worked out why CefSharp would not run in LinqPad.
Here are the steps to make it run -
Add CefSharp.Offscreen.NetCore package as normal to query
Enable Copy all NuGet assemblies into a single local folder (F4->Advanced)
Add the OnInit() and queryPath code as below to the query
Ensure the BrowserSubprocessPath is set before Initializing Cef
Here is the code.
async Task Main()
{
var are = new AutoResetEvent(false);//my technique for waiting for the browser
var sett = new CefSettings();
sett.BrowserSubprocessPath = this.queryPath + #"\CefSharp.BrowserSubprocess.exe"; //CefSharp will complain it cant find it
if (!Cef.IsInitialized)
Cef.Initialize(sett);
var browser = new ChromiumWebBrowser("http://www.google.com");
browser.LoadingStateChanged += (sender, args) => { if (!args.IsLoading) are.Set(); };
are.WaitOne();
await browser.WaitForInitialLoadAsync();
var html = await browser.GetBrowser().MainFrame.GetSourceAsync();
html.Dump("winner winner chicken dinner");
}
//this is the location of the queries shaddow folder
string queryPath = Path.GetDirectoryName(typeof(CefSettings).Assembly.Location);
void OnInit() // Executes when the query process first loads
{
if (!Directory.Exists(queryPath + #"\locales")) //subdirectory of cef.redist
{
var nugetPath = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile);
var sources = new[] {
/*paths here are hardcoded version dependant. Can get cefsharp.common.netcore version
from Util.CurrentQuery.NuGetReferences, but cef.redist not available via that method. */
#"cef.redist.x64\95.7.14\CEF", //contans all the Cef dependencies needed
#"cefsharp.common.netcore\95.7.141\runtimes\win-x64\lib\netcoreapp3.1", //mainly for ijwhost.dll
#"cefsharp.common.netcore\95.7.141\runtimes\win-x64\native"}; //contains BrowserSubprocess & friends
var dst = new DirectoryInfo(queryPath);
foreach (var path in sources)
{
var src = new DirectoryInfo($#"{nugetPath}\.nuget\packages\{path}");
CopyFilesRecursively(src, dst);
}
}
}
//curtesy of https://stackoverflow.com/a/58779/2738249 with slight mod
public static void CopyFilesRecursively(DirectoryInfo source, DirectoryInfo target)
{
foreach (DirectoryInfo dir in source.GetDirectories())
CopyFilesRecursively(dir, target.CreateSubdirectory(dir.Name));
foreach (FileInfo file in source.GetFiles())
{
var dst = Path.Combine(target.FullName, file.Name);
if (!File.Exists(dst))
file.CopyTo(dst);
}
}
The why for those interested -
CefSharp needs every dependency to be in the same directory so they can be resolved at runtime, but Linqpad only copies a few key dll's from the NuGet package. None of the cef.redist files, ijwhost.dll or BrowserSubprocess.exe et al. come across. Dependencies are scattered between NuGet packages and trying to resolve them directly from the .nuget cache just does not work. So all these need to be brought in manually to the running query shadow path.
I did initially copy all files into the Assembly.GetExecutingAssembly().Location path, but this approach requires adding the assembly directory to the "path" environment variable.
Internally Linqpad seems to have the shadow path set, so copying the dependencies to the shadow folder skips the need to set the environment variable.
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.
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'm now localizing my WPF application and there is this little piece of code in the constructor of the MainWindow:
System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(Settings.Default.Language);
It crashes right after I start it, saying:
XmlParseException:{"'The invocation of the constructor on type 'Program.MainWindow' that matches the specified binding constraints threw an exception.' Line number '3' and line position '9'."}
its inner: CultureNotFoundException: Culture is not supported. Parameter name: nameen-UK is an invalid culture identifier.
Now I know that there is no such a culture name as en-UK. I just typed it once by accident... I thought there was.
Now everything contains: en-GB. (settings, appconfig, etc.)
Steps I have done:
restart devenv
delete all the bin and obj folders.
search in the entire solution for the expression: "en-UK" (with and without case sensitivity)
search with total commander for "asterisk dot asterisk" containing the text: "en-UK" (with and without case sensitivity)
no results...
Then I put a breakpoint into the constructor and the
Settings.Default.Language
has the value "en-UK".
The point: everything works fine in release mode. It occurs only in Debug mode. How is this possible?
in release mode, the Settings.Default.Language has the en-GB value (which is fine).
Have you met this problem before? Is it a Visual Studio bug or did I go mad? Thank you.
in Visual Studio the debug mode or the release mode each one have a separated config file;
so when you debug with Debug config the old config info still registered;
try to make like this in the constructor:
Setting.Default.Reset();
if this not help you please post some code for more detail.
Having a problem with SharpSVN (1.5 and 1.6) checking out code. (Note, I also have Tortoise 1.5 installed on my machine)
This same code has worked previously, so I don't know why things might have broken.
using (SvnClient client = new SvnClient())
{
SvnUriTarget url = new SvnUriTarget(checkoutURL.ToString());
client.Authentication.DefaultCredentials = new NetworkCredential(userName, password);
return client.CheckOut(url, destinationPath, out result); //error happens here
}
This code pulls Down a copy from SVN. It creates a copy into a directory named Sandbox.
Nothing has changed (except my own System configuration, I'll get to that in a minute), however, now I get the error:
SharpSvn.SvnException:
Can't open file '..\..\..\TestHarness\Sandbox\testBuild\Trunk\TestProjects\XX\Source\XX.TestHarness\Tests\Service\_svn\tmp\text-base\IViewProject_Tester.cs.svn-base':
The system cannot find the path specified.
Now this is crazy. This has pulled down fine before. For it to tell me to run "Cleanup" insinuates that there was a working copy there previously!
Also, you can also see that SharpSVN thinks that the .cs file is inside the _svn directory!
About my setup..
my system has Tortoise 1.5 on it (after downgrading from Tortoise 1.6 to see if I could fix this problem.. no go..
since I am a .net developer, I did set up Tortoise to use _svn folders
Any clues? Even questions are welcome..
ok,
Apparently this is an unresolvable bug that is tied to the max length for relative file paths in Windows.
Bert Huijben answers the issue pretty well here.
http://sharpsvn.open.collab.net/ds/viewMessage.do?dsForumId=728&dsMessageId=331173
Solution: Ditch the relative path and Use a Fully Qualified path