I am trying to read a GIF file header into a structure with F#, using Mono 5.8 on Mac OSX. The following code sample works fine in Visual Studio 2017 on Windows 10; however, when I try to run it in Visual Studio for Mac, I get the following error in F# interactive:
* Assertion at class-accessors.c:138, condition `mono_class_has_static_metadata (klass)' not met
The code I am using is below. The structure is probably incorrect since I just threw it together quickly for the question, but
open System
open System.IO
open System.Runtime.InteropServices
[<Struct; StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi, Pack = 1)>]
type GifHeader = {
[<MarshalAs(UnmanagedType.ByValTStr, SizeConst = 3)>]
signature: string
[<MarshalAs(UnmanagedType.ByValTStr, SizeConst = 3)>]
version: string
logicalWidth: int16
logicalHeight: int16
}
When I invoke Marshal.SizeOf(typeof<GifHeader>) in Visual Studio for Mac's FSI, I get the error mentioned above.
I noticed that when I am reading into a structure like:
[<Struct; StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi, Pack = 1)>]
type SomeOtherHeader = {
field1: uint16
field2: int32
field3: int16
field4: float
}
i.e. with no MarshalAs UnmanagedType specification, the error is not thrown.
Does anyone know what this error means? I haven't seen any other instances of this particular error on Google or other SE posts, and it is especially puzzling since it doesn't occur on Windows/.NET Framework 4.7. Not having the interactive window to test code is a massive hindrance for learning, and quite frustrating since I don't think it's possible to use an alternative (non-Mono) FSI.
This was an issue intrinsic to the current Mono release. Per the Mono team, this has been fixed as of Mono 5.14.
Related
Problem running Plotly.NET on F# Interactive. (VS2019, FSharp Core 7.0.0, Plotly.NET 3.0.1, TargetFramework: net472)
#r C:\....\.nuget\packages\plotly.net\3.0.1\lib\netstandard2.0\Plotly.NET.dll"
open Plotly.NET
let xData = [0. .. 10.]
let yData = [0. .. 10.]
let myFirstChart = Chart.Point(xData,yData)
Gives an error: " C:\...\AppData\Local\Temp\1\unknown(1,1): error FS3216: type 'Plotly.NET.GenericChart+GenericChart' not found in assembly 'Plotly.NET, Version=3.0.0.0, Culture=neutral, PublicKeyToken=.......'. A possible cause may be a version incompatibility. You may need to explicitly reference the correct version of this assembly to allow all referenced components to use the correct version."
What should be correct configuration for environment to get that running?
I'm not sure why you mention "TargetFramework: net472". Also I'm puzzled by your mention of "FSharp Core 7.0.0", since F# interactive is going to be tied to some specific version of F#, for VS 2019 that won't be 7.0.
It's better to use the new syntax for referencing a nuget package from a script:
#r "nuget: Plotly.NET"
I tried your code in VS 2019 (referencing the nuget package as above) and still got a weird error. I then went to Tools | Options | F# Tools | F# interactive and changed the option "Use .NET Core Scripting" from false to true. I then reset the F# interactive session to make the change take effect, and tried your code again, and it worked.
> let myFirstChart = Chart.Point(xData,yData);;
Binding session to 'C:/Users/jimfo/.nuget/packages/plotly.net/3.0.1/lib/netstandard2.0/Plotly.NET.dll'...
Binding session to 'C:/Users/jimfo/.nuget/packages/dynamicobj/2.0.0/lib/netstandard2.0/DynamicObj.dll'...
val myFirstChart: GenericChart.GenericChart =
Chart
(Plotly.NET.Trace2D, Plotly.NET.Layout, Plotly.NET.Config,
Plotly.NET.DisplayOptions)
I didn't bother testing 32 bit vs 64 bit or seeing what happens in VS 2022.
I don't know what the errors are about, I have seen some strange errors lately given the mix of F# compiler versions, FSharp.Core versions, VS versions (think of all the patched versions), and sometimes you have to just fool around a bit until you get the right combination that works.
I try to get the Z3 solver up and running in F#. So I created a fresh F# project in Visual Studio, added a reference to Microsoft.Z3.dll, and typed in the following code:
open Microsoft.Z3
let ctx = new Context()
let a = ctx.MkBoolConst("a")
Running this in the interactive window yields the following error:
System.InvalidCastException: Unable to cast object of type 'Microsoft.Z3.AlgebraicNum' to type 'Microsoft.Z3.BoolExpr'.
at Microsoft.Z3.Context.MkBoolConst(String name)
at <StartupCode$FSI_0013>.$FSI_0013.main#() in C:\Users\...\Program.fs:line 3
Stopped due to error
What am I missing?
This sounds very much like https://github.com/Z3Prover/z3/issues/1882
You might have to recompile/reinstall. Follow the instructions in that ticket.
I'm using the Microsoft.Office.Interop.Excel library (version 14.0) from an F# application and I can't seem to be able to reference some of the properties defined in Interop's interfaces/classes.
For example, if I have a Worksheet object I can't do the following:
let sht = // Get the Worksheet
sht.PageSetup.CenterHeader <- // Set the header
It can't find CenterHeader as a property of the PageSetup interface, even though it's there if I view the Interop dll in the object browser.
Just for reference, the Interop dll that I'm using is from the VS directory: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Visual Studio Tools for Office\PIA\Office14\Microsoft.Office.Interop.Excel.dll
Update:
I actually spoke too soon. Unfortunately the suggested solution with the cast didn't work either. VS thinks it's OK but it fails at runtime with the following error:
Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.Office.Interop.Excel.IPageSetup'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{000208B4-0001-0000-C000-000000000046}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
As I said in the comments, F# doesn't support type equivalence for embedded interop types, so if a C# project has Embed Interop Types enabled then the F# compiler may be unable to determine which version of the interop type to use. Since the type embedded in the C# output assembly has been stripped down to only the members used, this can make it so that the F# compiler is unable to see members that are present in the version of the type from the primary interop assembly.
The workaround is to turn off Embed Interop Types on the C# project.
This works for me:
#if INTERACTIVE
#r "office"
#r "Microsoft.Office.Interop.Excel"
#endif
open Microsoft.Office.Interop.Excel
let setCenterHeader fileName worksheet header =
let file = System.IO.FileInfo(fileName)
let excel = ApplicationClass()
try
// Make sure to use full path since this will
// be interpreted as relative to Excel's process,
// not currently executing one
let workbook = excel.Workbooks.Open(file.FullName)
let sheet = workbook.Worksheets.[worksheet] :?> Worksheet
sheet.PageSetup.CenterHeader <- header
workbook.Save()
finally
excel.Application.Quit()
setCenterHeader "TestWorksheet.xlsx" "Sheet1" "My header 1"
setCenterHeader "TestWorksheet.xlsx" "Sheet2" "My header 2"
setCenterHeader "TestWorksheet.xlsx" "Sheet3" "My header 3"
You might want to make sure you have matching versions of PIA and Office installed/used.
I have 2 files: Asm.fs, AsmTest.fs
Asm.fs
namespace Assembler
[<Measure>] type ln
[<Measure>] type col
[<Measure>] type port
type Addr = int<ln> * int<col> * int<port>
module Asm =
let emptyAddr : Addr = (-1<ln>, -1<col>, -1<port>)
AsmTest.fs
module Assembler.Tests
[<Test>]
let someTest() =
let x = Asm.emptyAddr
When I debug someTest() code, I get that x = null, what am I doing wrong?
P.S. files in the different projects visual studio projects. Asm.fs in the Assembler project and AsmTest.fs in the AssemblerTest project.
I found an interesting behavior. My problem will be resolved, if I add some file (even empty) to the Assembler project. Can anyone explain this behavior?
The debugger sometimes has issues showing the correct values. For me however, having exactly the same Asm.fs and AsmTest.fs like this:
module Assembler.Tests
open NUnit.Framework
[<Test>]
let someTest() =
let x = Asm.emptyAddr
Assert.IsNotNull x
the test passes and if I set a breakpoint at the assertion, x is correctly shown as {(-1, -1, -1)}
As the code that you show does not compile as it is (Block following this let is unfinished. in someTest), could you try my test above and/or show your complete test method?
Using your code I can reproduce the behaviour. If I set my projects to console applications, my test will fail as well. So, it seems that for console projects, not having any other file or an [<EntryPoint>] surprisingly skips the initialization of module values. For me, the compiler at least issues a warning Main module of program is empty where I use x in the test. The solution to the problem is therefore:
make sure you treat warnings as errors
have an [<EntryPoint>] for console applications
use library projects for libraries
I can't seem to get the SqlProgrammabilityProvider to work even in the most basic configuration. With this code
type TestDb = SqlProgrammabilityProvider<testConn>
let db = TestDb()
I get the design/compile-time error "The value or constructor 'TestDb' is not defined"
testConn is a literal string that is working fine with the SqlCommandProvider in the same project.
I'm using VS 2015, FSharp.Data.SqlClient 1.7.5, and I've tried targeting .NET 4.5.2 and 4.6.
Are there known issues or limitations with this? If not, how could I troubleshoot it?
After getting a type for SqlProgrammabilityProvider upon a specific connection you should tie it to as many as you like, but of the concrete following options: Sql Server function, stored procedure, or table.
Like in:
type TestDb = SqlProgrammabilityProvider<testConn>
type Datatable = TestDb.dbo.Tables.MyDataTable
or
use cmd = TestDB.dbo.MyStoredProcedure()
cmd.Execute(Param1="xyzzy")
You may peek at use cases at https://github.com/fsprojects/FSharp.Data.SqlClient/tree/master/src/SqlClient.Tests