Thanks Anton - changing the encoding fixes the compilation issues with the generated defs files.
I’m still getting the DALINQ invalid operation errors though. Any thoughts on these?
Alan
Thanks Anton - changing the encoding fixes the compilation issues with the generated defs files.
I’m still getting the DALINQ invalid operation errors though. Any thoughts on these?
Alan
Seems to be a compiler issue (this error reproduces without Data Abstract as well).
Seems compiler threats System.Nullable<Boolean>
and nullable Boolean
differently (despite that on IL level this is exactly the same type)
Still let me check if I can provide a workaround here
I wasn’t able to come up with a workaround, and was unable to get in contact with Carlo re: the compiler. I’m not sure what the weekend schedule is for RO employees…but if there is any chance that part or all of this could be resolved over the weekend, please drop me a message to let me know.
All the help this week is very much appreciated!!
Alan
Carlo is off until Tuesday, due to Monday being a holiday for him. If this is caused by System.Nullable<Boolean>
vs nullable Boolean
, wouldn’t an easy workaround be to just replace the type name in the generated code?
As a side note, please remember that DA 9.5 is a beta release, ad as such expected to have bugs and regressions, as things are in flux and beta builds don’t get the full QA cycle. One cannot really expect weekend emergency response for beta builds…
Please check your personal downloads folder. A new build should be available there.
I understand 100% that its a beta and in flux. I also totally understand weekend hours…but it never hurts to ask, right?!
Thanks Anton! I owe you for this week!
OK. Once again, thanks for the new build Friday afternoon. Much appreciated.
Good new and bad news.
Good news - I installed the new DA build, updated Relativity server on my server, started relativity, in Elements I updated the table defs from the server, and my client lib compiled without any errors, so those problems with the table defs appear to have been fixed.
Bad news - I rebuilt my console test app that uses this lib, and when I ran it from the command line - I saw none of my apps output, but got this:
Unhandled Exception: System.TypeLoadException: GenericArguments[0], 'System.ValueType', on 'System.Nullable`1[T]' violates the constraint of type parameter 'T'.
at RelativityTest.Program.Main(String[] args)
My first line of code in my app is what Elements adds in: Writeln(“The magic happens here”);
I don’t even see that.
How do I go about debugging this error?
Alan
Hello
At first TypeLoadException
is one of the worst types of exceptions - there is no stacktrace. CLR raises this exception when something bag happens during assembly load, so there is no stacktrace, just a message. One needs to analyze it and offending assembly’s source code to find out the cause (this can be really hard at times).
Regarding this particular error - its message is really odd. The compiler just won’t allow a code to compile if it contains anything breaking this particular constraint.
So please do the following:
\obj
subfolders. VS caches there build artifacts and sometimes even Clear
and Rebuild
commands issues from withing Visual Studio do not clear these folders. Then rebuild the app and try to run it again.If the error is still there then please send to support@ the full source code AND compiled application
Regards
I can’t seem to send emails to support@
Could you check to see if there is an issue on your end?
thanks
OK, this is very very strange…
I reverted back to DA 9.4 because I have to get some data processing done today.
Just for fun, I rebuilt my client lib and test app with 9.4.
I"m getting the same damn typeload exception. WHY??!!??
The only other possibility would be Friday’s new beta of Elements. I’m reverting back to the previous Elements 10 beta and will let you know if that gets rid of this exception. I’m suspecting a bug in the compiler…
OK, this is very very strange now.
I reverted back to the previous weeks beta of Elements 10, and on DA 9.4, I did a full rebuild after deleting the obj directories just to be safe…and i’m still getting this typeload exception. this makes no sense at all.
After reverting did you also regenerate the TableDefs file?
yes I did, which confuses me more
Any chances that something was missed? Like some utility assembly/project, postbuild action etc?
I know - it doesn’t make any sense. This all started when I installed the new version you gave to me on Friday.
what i’m going to try and do today when I find time is to make a new test app. something isn’t right, but I can’t see anything wrong, so I figured the best approach is to make anew test app and go from there.
OK, so Carlo got me a new build of Elements 10, but I was still getting the typeload exception. I started to comment out code in my little test app, and I found the code that is causing the Typeload exception.
This is what is causing it:
var d1: System.Nullable<Double>;
var d2: System.Nullable<Double>;
d1 := new DateTime(2018,5,1).ToOADate;
d2 := new DateTime(2018,5,18).ToOADate;
var HistMain := (from apr in fDataModule.DataAdapter.GetTable<aprecon>
where ((apr.StartDateTime >= d1) and (apr.StartDateTime <= d2))
where (apr.PostDateTime<>0)
select apr).ToList;
It must have something to do with declaring the System.Nullable vars.
I had to do this to match up w/ the new DA 9.5 CodeGen/table definitions.
I hope this helps.
Alan
Logged this for Carlo (as it reproduces without Data Abstract too).
Do you have any variables declared as System.Nullable<...>
? If so then try to change their type to nullable ...
- this should help.
Note that the latest DA build uploaded for you should also generate nullable data types as nullable ...
, not as System.Nullable<...>