I'm getting the following exception from System.IO.Path.CheckInvalidPathChars() in mscorlib:
[ArgumentException: Illegal characters
in path.]
System.IO.Path.CheckInvalidPathChars(String
path) +142
System.IO.Path.NormalizePath(String
path, Boolean fullCheck, Int32
maxPathLength) +100
System.IO.Path.GetFullPath(String
path) +187
System.Xml.XmlResolver.ResolveUri(Uri
baseUri, String relativeUri) +114
System.Xml.XmlTextReaderImpl..ctor(String
url, XmlNameTable nt) +135
System.Xml.XmlDocument.Load(String
filename) +85
Sitecore.Web.UI.WebControls.WebEditRibbon.ConvertToJson(String
layout) +210
Sitecore.Web.UI.WebControls.WebEditRibbon.Render(HtmlTextWriter
output, Item item) +1268
Sitecore.Web.UI.WebControl.Render(HtmlTextWriter
output) +387
System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter
writer, ICollection children) +246
System.Web.UI.HtmlControls.HtmlForm.RenderChildren(HtmlTextWriter
writer) +315
System.Web.UI.HtmlControls.HtmlContainerControl.Render(HtmlTextWriter
writer) +48
System.Web.UI.Control.RenderControlInternal(HtmlTextWriter
writer, ControlAdapter adapter)
+11279890 System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter
writer, ICollection children) +246
System.Web.UI.Page.Render(HtmlTextWriter
writer) +40
System.Web.UI.Page.ProcessRequestMain(Boolean
includeStagesBeforeAsyncPoint, Boolean
includeStagesAfterAsyncPoint) +5274
The thing is, I don't what the path value is that's causing this error. It would help if I could debug the method so I can see the value of the path parameter. I enabled stepping into the .Net Framework code in Visual Studio 2010. I've also loaded the related .Net Framework Symbols from the Microsoft Symbol Servers. However, it seems these PDBs don't include the source; so I can't step into CheckInvalidPathChars and retrieve the path value.
Is it possible to debug mscorlib and step through its source?
Relevant info:
.Net Framework 4.0.
Visual Studio 2010
Any constructive input is greatly appreciated.
Thanks,
Frank
You can get the reference source for the .NET libraries.
http://referencesource.microsoft.com/
Looking at your stacktrace, the problem appears to be originating in Sitecore.Web.UI.WebControls.WebEditRibbon.ConvertToJson. That thing is trying to load an XML file.
Using reflector would allow you to do that.
Is it possible that you enabled to break on all exceptions? Doing that would certainly account for internal exceptions showing up in the debugger. If this is the case, you can safely ignore the exception.
Well mscorlib.dll on your machine is of release build so even though you can very well debug into it, you won't be able to see values local variables/objects etc. The code in this binary is optimized. If you want perfect debugging experience of Microsoft .NET code then you will need to install debug version of .NET on your machine.
Related
`
Severity Code Description Project File Line Suppression State
Error MSB4018 The "VCMessage" task failed unexpectedly.
System.FormatException: Index (zero based) must be greater than or equal to zero and less than the size of the argument list.
at System.Text.StringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.Format(IFormatProvider provider, String format, Object[] args)
at Microsoft.Build.Utilities.TaskLoggingHelper.FormatString(String unformatted, Object[] args)
at Microsoft.Build.Utilities.TaskLoggingHelper.LogErrorWithCodeFromResources(String messageResourceName, Object[] messageArgs)
at Microsoft.Build.CPPTasks.VCMessage.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() xbLive C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets 460
`I dont know why it is giving me this error. I am rebuilding an old project and I can't seem to find the right build tools needed in order to run the solution correctly.
I tried v143 build tools for 2022 and did all the components. I attempted to get build tools from earlier builds of the project. There is no documentation for me to refer to and this is something I would like to pursue. I just dont know where to find the correct stuff. If it is even in the source code, I wouldn't know because I havent tried looking there. I wouldnt even know where to look.
Sorry for all the long error messages! I wonder if there is something wrong with my Xamarin, or Mono install which is breaking FSI on Xamarin? Default .Net runtime is Mono 4.6.2 Although I have installed Mono 4.8.0, Xamarin is running on 4.6.2
I wonder if these error messages mean that FSI isn't loading the System.Drawing module? And why is SOURCE_DIRECTORY seemingly not working? There are no errors displayed in the .fsx file but when loaded into FSI it doesn't work.
I've also got Visual Studio for Mac installed. I'm just starting with F# (day 3) and this is the first time I've tried to open a System module so I've not idea if it ever worked. Basic functions I write myself will evaluate in FSI. I'm considering the possibility that the install has been screwed up somewhere and am wondering if I should just remove .Net, Xamarin and Mono and reinstall from scratch? Is it possible for Visual Studio to interfere with Xamarin?
Going through the FSharp TV intro course I'm running the following errors
F# in a .fsx file:
open System.Drawing
let bitmap = new Bitmap(32,32)
let path = __SOURCE_DIRECTORY__ + "/"
bitmap.Save (path + "large.png")
Loading the entire code block in FSI throws:
System.Exception: Generic Error [GDI+ status: GenericError]
at System.Drawing.GDIPlus.CheckStatus (System.Drawing.Status status) [0x0007a] in <1917aa1c39d94b1a91807b8cd9f03350>:0
at System.Drawing.Image.Save (System.String filename, System.Drawing.Imaging.ImageCodecInfo encoder, System.Drawing.Imaging.EncoderParameters encoderParams) [0x00043] in <1917aa1c39d94b1a91807b8cd9f03350>:0
at System.Drawing.Image.Save (System.String filename, System.Drawing.Imaging.ImageFormat format) [0x0004c] in <1917aa1c39d94b1a91807b8cd9f03350>:0
at System.Drawing.Image.Save (System.String filename) [0x00008] in <1917aa1c39d94b1a91807b8cd9f03350>:0
at (wrapper remoting-invoke-with-check) System.Drawing.Image:Save (string)
at <StartupCode$FSI_0004>.$FSI_0004.main# () [0x0003d] in <2545683d6122431b9ff3a69ce9ec460c>:0
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00038] in <8f2c484307284b51944a1a13a14c0266>:0
Loading only SOURCE_DIRECTORY in FSI returns:
val it : string = "/"
which is weird because that's not the correct path
Loading the line: let bitmap = new Bitmap(32,32)
throws:
Stopped due to error
System.Exception: Operation could not be completed due to earlier error
The type 'Bitmap' is not defined at 2,4
Sending System.Drawing to FSI
throws:
Stopped due to error
System.Exception: Operation could not be completed due to earlier error
The value, constructor, namespace or type 'Drawing' is not defined at 2,7
It looks like you might be hitting a Mono bug. I've found several reports of what looks like the same bug (though it's possible that it's several different bugs). The most useful one appears to be this Github issue: https://github.com/gitextensions/gitextensions/issues/2226
I don't know if that will help you; that issue appears to have been resolved by upgrading from Mono 3.2.8 to the latest version of Mono available at the time. But you're already running what appears to be the latest version of Mono available to you, so "upgrade to the latest Mono" may not be the advice for your problem. But it's the best advice I'm able to give.
Also, in doing that search, I found several people complaining that libgdiplus (Mono's implementation of the GDIPlus API) was buggy in various ways. So in your shoes, I might skip the System.Drawing examples and move on to a different part of the tutorial if you can't get libgdiplus to work.
P.S. The below is what I first wrote in answer to your question, but then I experimented and discovered that the System.Drawing namespace is automatically loaded in F# scripts without you needing to explicitly open it. Still, as an F# beginner, you may find the information below to be useful in other contexts, so I've left it in. Just be aware that what I said below about System.Drawing not being automatically opened was wrong.
----- Not-quite-correct answer follows -----
When writing an F# script in a .fsx file, you can't just do open (namespace). You also have to tell F# where to find the .DLL with that namespace. In a compiled project (which uses .fs files), that information would be found in the .fsproj file. But for F# scripts (the .fsx format), there's no project file, so the script itself needs to specify which DLLs to load. You do this by the #r directive:
#r "/path/to/library.dll"
Or, if the DLL you're loading is installed in a standard system location such as the GAC (Global Assembly Cache), you can leave off the path and just do:
#r "library.dll"
There are a few DLLs that are automatically loaded whenever you run an F# script, such as mscorlib.dll that contains things like the System namespace. But the System.Drawing namespace is not one of those automatically-loaded DLLs. So before you can open the System.Drawing namespace, you have to put in the appropriate #r reference, like so:
#r "System.Drawing.dll"
open System.Drawing
I just upgraded to Xamarin studio 5.9 (build 431), and cannot run my project anymore. It works with a clean project though.
When I run my app, I don't even land in Main.
The Application Output in Xamarin studio prints a bunch of assembly loadings. It gets to MobileClientiOS.app/Newtonsoft.Json.dll [External], then it crashes with the following output:
Could not load file or assembly 'System.Threading.Tasks' or one of its
dependencies. The system cannot find the file specified.
(System.IO.FileNotFoundException) at System.AppDomain.Load
(System.Reflection.AssemblyName assemblyRef,
System.Security.Policy.Evidence assemblySecurity) [0x00081] in
.../mono/mcs/class/corlib/System/AppDomain.cs:706 at
System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef)
[0x00000] in .../mono/mcs/class/corlib/System/AppDomain.cs:674 at
System.Reflection.Assembly.Load (System.Reflection.AssemblyName
assemblyRef) [0x00000] in
.../mono/mcs/class/corlib/System.Reflection/Assembly.cs:551 at
ObjCRuntime.Runtime.CollectReferencedAssemblies
(System.Collections.Generic.List 1 assemblies,
System.Reflection.Assembly assembly) [0x00019] in
.../maccore/src/ObjCRuntime/Runtime.cs:218 at
ObjCRuntime.Runtime.CollectReferencedAssemblies
(System.Collections.Generic.List 1 assemblies,
System.Reflection.Assembly assembly) [0x0002c] in
.../maccore/src/ObjCRuntime/Runtime.cs:220 at
ObjCRuntime.Runtime.CollectReferencedAssemblies
(System.Collections.Generic.List 1 assemblies,
System.Reflection.Assembly assembly) [0x0002c] in
.../maccore/src/ObjCRuntime/Runtime.cs:220 at
ObjCRuntime.Runtime.RegisterEntryAssembly (System.Reflection.Assembly
entry_assembly) [0x0001b] in
.../maccore/src/ObjCRuntime/Runtime.cs:200 at
ObjCRuntime.Runtime.RegisterEntryAssembly (IntPtr a) [0x00000] in
.../maccore/src/ObjCRuntime/Runtime.cs:158 at
ObjCRuntime.Runtime.register_entry_assembly (IntPtr assembly)
[0x00000] in .../maccore/runtime/Delegates.generated.cs:118 at
(wrapper native-to-managed)
ObjCRuntime.Runtime:register_entry_assembly (intptr) 2015-05-04
MobileClientiOS[77830:1943120] critical: Got a SIGABRT while
executing native code. This usually indicates a fatal error in the
mono runtime or one of the native libraries used by your application.
Sorry for the long stacktrace, but I'm out of ideas. We are using PCL's, but there haven't been a problem before this Xamarin Studio-upgrade.
Thank you!
Edit:
I downgraded Xamarin.iOS and it's working again. The assembly it seems to fail on is (which now works with the old version):
/MobileClientiOS.app/System.Xml.Linq.dll [External]
How to be able to run with the latest version? I do not know.
To make a guess, I think this might have the same underlying cause as Xamarin Bug 29211.
If that's true, then there's a good chance the same workaround will work:
Under "project options -> iOS Build -> Additional mtouch arguments" add:
-linkskip=System.Threading.Tasks
If that workaround does indeed work, then it's very likely the issue will be fixed in the upcoming service release (due to be released later this week).
Update July 2, 2015
It turns out there is another subtly different common cause of the problem for System.Threading.Tasks. That second bug was originally hidden by Bug 29211 because the two bugs are very similar. The second problem is now being tracked in Xamarin Bug 31560. Note that this bug only affects simulator builds and has fairly simple workarounds, so it is minor in severity.
For some reason VS was not breaking on exception when running in debug mode, so I followed the advice given here to go to Debug -> Exceptions and enable the CLR exceptions. I now get this error:
System.Globalization.CultureNotFoundException occurred
Message=Culture is not supported.
Parameter name: name
uploads is an invalid culture identifier.
Source=mscorlib
ParamName=name
InvalidCultureName=uploads
StackTrace:
at System.Globalization.CultureInfo..ctor(String name, Boolean useUserOverride)
InnerException:
This error occurs on startup, but only some of the time.
The advice here then recommends that I do the exact opposite and uncheck the debug the CLR option, but I am then back to square one! A poster suggests that it is a bug, but the post is two years old, so surely that has been fixed by now.
I am not using globalisation.
I would like to add a small feature to QuantLib and compile it together with SWIG bindings to use in a C# project in Visual Studio 2010. I am however having problems at almost every turn. What are the steps involved in building QuantLib in Visual Studio 2010, creating the SWIG bindings, and building the C# project?
I downloaded QuantLib from http://sourceforge.net/projects/quantlib/files/
I downloaded Boost from http://sourceforge.net/projects/boost/files/boost/1.49.0/
I downloaded the QuantLib+SWIG bindings from http://sourceforge.net/projects/quantlib/files/QuantLib/1.0/bindings/QuantLib-SWIG-1.0.zip/download
I set an environment variable QL_DIR to "C:\pathToFolder\QuantLib-1.2\lib" (computer > properties > advanced system settings > advanced > environment variables)
I ran the swig.cmd file located in C:\pathToFolder\QuantLib-SWIG-1.0\CSharp
I opened QuantLib_vc9.sln in Visual Studio 2010
For the NQuantLibc project:
I included my Boost and QuantLib directories in the header directories.
I included my QuantLib/lib directory in the library directories.
I successfully built the NQuantLibc project
For the NQuantLib_vc9 project:
I made it dependent on the NQuantLibc project.
I successfully built the NQuantLib_vc9 project.
For the EquityOption_vc9 project:
I made it dependent on the NQuantLib_vc9 project.
I successfully built the EquityOption_vc9 project.
When I try to run the EquityOption_vc9 project, I get a TypeInitializationException, "An attempt was made to load a program with an incorrect format."
Here's the full exception:
System.TypeInitializationException was unhandled
Message=The type initializer for 'QuantLib.NQuantLibcPINVOKE' threw an exception.
Source=NQuantLib
TypeName=QuantLib.NQuantLibcPINVOKE
StackTrace:
at QuantLib.NQuantLibcPINVOKE.new_Date__SWIG_1(Int32 jarg1, Int32 jarg2, Int32 jarg3)
at QuantLib.Date..ctor(Int32 d, Month m, Int32 y) in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\Date.cs:line 48
at EquityOptionTest.EquityOption.Main(String[] args) in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\examples\EquityOption.cs:line 43
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException: System.TypeInitializationException
Message=The type initializer for 'SWIGExceptionHelper' threw an exception.
Source=NQuantLib
TypeName=SWIGExceptionHelper
StackTrace:
at QuantLib.NQuantLibcPINVOKE.SWIGExceptionHelper..ctor()
at QuantLib.NQuantLibcPINVOKE..cctor() in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\NQuantLibcPINVOKE.cs:line 126
InnerException: System.BadImageFormatException
Message=An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Source=NQuantLib
StackTrace:
at [long string removed]
at QuantLib.NQuantLibcPINVOKE.SWIGExceptionHelper..cctor() in C:\Users\JRobinson\Desktop\QuantLib-SWIG-1.0\CSharp\csharp\NQuantLibcPINVOKE.cs:line 106
InnerException:
Note that I built everything with the Debug configuation. I also tried this using the Release configuration. It didn't work.
I wish I could find a complete set of instructions detailing how to build this type of project. I found some instructions here, Compiling Quantlib via SWIG for C# but i couldn't get it to work.
The QuantLib page contains instructions for building QuantLib in Visual Studio 2010, http://quantlib.org/install/vc10.shtml but I need help creating the SWIG bindings.
Resolver Systems has pre-built C# bindings that work for me. http://www.resolversystems.com/products/quantlib-binary/ I was able to run QuantLib code in C# just fine with this package. My problem is that I need to add a small feature to the QuantLib code for use in my C# project. This is the reason I need to re-build QuantLib and re-create the SWIG bindings.
I know about QLNet, the C# port of QuantLib, http://sourceforge.net/projects/qlnet/, but this project is missing some pieces and I think that it is no longer being actively developed. Specifically, I need to be able to price options that pay discrete dividends. QLNet is missing some of the code for this. I tried porting the necessary code from QuantLib to QLNet, but my C++ must be rusty because I was getting incorrect output.
Note that the small feature I need to add to QuantLib is the ability to handle fractional days. I was able to add this feature to QLNet, and it is a small feature indeed. This tiny edit is delaying my project. I would greatly appreciate help on this issue.
There indeed seems to be a problem with the SWIG wrappers as distributed and .Net 4.0.
I'm not working on that platform, so I can't speak based on personal experience. However, the issue was discussed recently on the QuantLib mailing list, and the solution contributed there by Mark Gillis was reported to work. You can read the relevant thread at http://thread.gmane.org/gmane.comp.finance.quantlib.user/8238. Hope this helps...
I struggled with this exact error message a little while back, and visited this page, as Google search might say, "many times".
In the end, my error was fairly benign, but it took me a while to sort it out.
I was using C# wrappers by SWIG to access QuantLib C++ library. I used Excel DNA Integration to make my Quantlib.xll, and I also built a few .exes that access Quantlib.
Various situations would cause this error to appear for me, most especially
Running the .exes off of my desktop ("sometimes")
Distributing my XLL to other users (always).
In the end, I discovered that the distribution that I was getting from the bin folder of my VS2010 (and 12, 13, 15) projects included NQuantLib (the C# wrapper code) but did not include NQuantLibc (the C++ unmanaged code being called).
The XLL and the exes worked on my machine sometimes because I probably helped them (via changing my path?) to find the missing C++ code, but I did not recall that step in the process.
Once I figured it out (using a StackOverflow hint to check the "inner exception" on the error when running the code on another machine and opening up VS to debug when it bombed), the problem went away.
A bit of ignorance on my part that cost me a bit of time but earned me a bit of experience:
this error, for me, was caused by not putting the unmanaged (C++) library where the managed (C#) library could find it.