The following query works in Debug mode only:
private IQueryable<UserState> UsersOfEmail(string email)
{
return this.realm.All<UserState>()
.Where(u => u.EmailAddress == email);
}
When in Release mode, I get the error:
The rhs of the binary operator 'Equal' should be a constant or closure variable expression
I found a workaround for the error, but it doesn't seem to apply here.
When I check the Enable debugging option for the project (iOS, in this case), it works fine, which is why it was working in Debug mode only in the first place.
Any clue on the relationship between the error and the debugging option?
UPDATE
After further investigation, I found out that this issue has no relation to Realm.
I was misusing the event pub-sub feature of Prism (MVVM framework, among other things), and subscribing multiple times to an event in a view model of a page that would be navigated to and from, without unsubscribing in each interaction.
I thought this was a Realm issue because I didn't realize at first that the email parameter was null when in Release mode.
By using the pub-sub correctly, I was able to mitigate the problem. I still don't have an answer as to why it was only happening in Release mode, even though the Linking option was disabled in both build modes.
We have a new release coming out soon which uses relinq to handle expression parsing and should dramatically improve how we handle linq, especially for this kind of expression.
It will be the next release after 0.77.2.
However, you are the first to identify something failing only in a Release mode so there may be something more complex going on.
Is there any difference in the Linking settings between your simple and complex apps? Maybe linker stripping is causing some problems.
Related
I'm trying to port my console app over to a Blazor app. Everything worked fine inside the console type project, but it's not inside the Blazor project so I'm trying to troubleshoot. The app calls some things from a separate "class library" type project within the same solution.
The troubleshooting process itself is having issues of its own though. After a little bit of confusion I realized that the breakpoints set inside the referenced class library type project's code are not being hit.
Checking to console, I see it gives the error:
L: Unable to insert breakpoint at FtxApi.FtxWebSocketApi/<Test>d__5:MoveNext ():15
Is there anything I need to do (project settings or something) for the debugger to hit these? Or is it not supported at the moment?
Right now I'm just using a lot of Console.Writeline sort of as a workaround/replacement. And I noticed that the Console.Writelines inside the referenced class library type project are being called.. but only up to a certain method call that comes from a third party package. Execution seems to return from that point (nothing is called after it). Not sure what's going wrong there - more troubleshooting is needed, which brings us back to the breakpoints not firing (ideally I'd be able to make use of them).
I understand Blazor is new (and I'm an absolute beginner at using it), so not everything needs or is going to be perfect. I'm asking about the breakpoints kind of out of curiosity (I'd like to get them working but no big deal otherwise).
What I'd really like some insight into is: What might be going on with the code seemingly stopping execution / returning at that one particular method call? The method I'm calling is WebSocket.Open(), from the package WebSocket4Net. As mentioned above, I've tested this before (in a Console app) and it worked fine, so I'm guessing it's somehow related to Blazor which I'm unfamiliar with. I'm unsure how to get any more info to help debug this problem. Any help appreciated.
Edit:
I managed to find a solution to my problem without the use of debugging tools like breakpoints and such (I just used Console.Writeline a lot). I guess Blazor does not support some websocket implementations or something, because I found this error: System.PlatformNotSupportedException: Operation is not supported on this platform. blazor.webassembly.js:1 at System.Net.Sockets.Socket coming from websocket.Open(). I managed to get it working by implementing System.Net.Websockets instead, similar to this. Though my troubleshooting is over (for now), I'm still wondering if it's somehow possible to use breakpoints inside other referenced projects.
There are 2 solutions:
Solution 1: Right-click at Solution, choose Properties, choose Common Properties, Choose Multiple startup project, choose Action Start for Foo.Client, Foo.Server, Foo.Shared . Something like this
See https://blog.magnetismsolutions.com/blog/paulnieuwelaar/2015/04/07/debug-multiple-projects-at-the-same-time-in-visual-studio
Solution 2: Compile SharedProject, attacht PDB for debugging.
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-an-executable-not-part-of-a-visual-studio-solution?view=vs-2019
When using CSScript.Evaluator.Reset(), will this reset anyone else that is currently using the same script or build?
Another way of asking my question.
script = CSScript.Evaluator.LoadCode(scriptString);
If another user came thru and called the same code, but an error occurred.
Would the original compile still be good and safe?
Also CSScript.Evaluator.AutoResetEvaluatorOnError = true, this does not seem to be working.
After i cause an error in the code, then fix it. The compile will not work til i reset my app, or use Reset().
Using Reset is working, But that's the reason for my initial question.
I am using CSScript.Evaluator.LoadCode and looking at CSScript.Evaluator.LoadMethod, but getting the same issues.
These are not huge scripts, but may run in large batches or loops.
Not against unique naming, cause i will have build for every run anyway.
But i'm not sure the cache is working either.
Where is the location of the cache folder, when CSScript.CacheEnabled is enabled?
Would the original compile still be good and safe?
Yes it would as when you hold the reference to the compiled object it is YOURS. I is good even if you destroy the compiler.
Also CSScript.Evaluator.AutoResetEvaluatorOnError = true, this does not seem to be working.
This setting triggers so cold SoftReset, which is different to the Reset only by re-referencing the assemblies and re-creating the CompilerSettings object. It the time of the initial implementation SoftReset was sufficient to fully clear Mono.Evaluator. I will need to check may be it is not the case any more. I will let you know the outcome.
Where is the location of the cache folder, when CSScript.CacheEnabled is enabled?
The caching doesn't cover Mono Evaluator as the all assemblies are in the memory and cannot be cached.
Everything that is accessed through CSScript.Evaluator.* applicable to the Mono compiler and everything that it accessed through CSScript.* is a CodeDOM compiler, which indeed implements caching mechanism.
I'm having a weird problem with Visual Studio 2010 Ultimate:
One of my Nunit(2.6.2) test cases is failing in the debug mode but passing in the run mode, as if we had completely different code paths for the two scenarios.
Is this a known bug? or is there some option in vs I'm missing?
Please enlighten me!
Thanks a lot.
EDIT - MORE INFORMATION
My application submits some requests to a dll written by a group of people within the organization. The dll does some computation and returns the results back to me.
In a test case exploring the dll's behavior (e.g. submit a request having certain parameter, check the dll's output), running the Nunit test works fine, but debugging the test case gives me an error - an exception was thrown from within that dll.
IMPORTANT: Running/debugging another test case gives me consistent results.
So, for the weird test case:
1, either the dll is good, and something under the debug mode breaks the dll
2, or, the dll has a bug, which is triggered by something under the debug mode.
To my knowledge, the ONLY difference between running and debugging a piece of code in visual studio is that, when debugging, a pdb file is loaded while when running it's not. Essentially, a symbol table is loaded to identify code execution.
Then the issue doesn't make sense in the first place - why would loading a symbol table affect the dll's behavior? (It's unfair to ask anyone to give an explanation without seeing any code; however, since it's corporate prop. code, I can't show it here. Please, if you've ever encountered such things in your career, do share with me what happened in your case - let's hope my problem has the same cause so that I can actually know what went wrong. Thanks)
Are you using code coverage?
If so, try disabling it and run. It will probably work.
For more details, check: http://social.msdn.microsoft.com/Forums/en-US/aba3d58f-f19f-4742-b960-8ac2be29bb88/unit-test-passes-when-in-debug-but-fails-when-run
You may have run into a situation where you're taking the same code path, but the results are subtly different in debug vs non-debug due to optimizations. There are a couple of distinct possibilities here:
Your code has a subtle bug, e.g. a race condition
Your test is being overly specific, e.g. for floating point comparisons where you should use a tolerance
It's a pain not being able to debug, but I suggest you add logging throughout the method and the test so you can see what's going on. (And hope that the logging itself doesn't change the test result, which is also possible...)
Thank you for your response.
I've identified the reason: it's due to a false parameter which drives the dll nuts. My bad.
It still doesn't answer the question why the behavior at debug time goes crazy, but good while running the test case.
However, I guess, since the parameter is wrong in the first place, I can't really blame the dll for going nuts. Anyway, when I passed in the correct param, all went good.
Thanks a lot guys.
I am having a very frustrating problem in Visual Studio. I am using Resharper, and writing tests in Nunit.
If I set a breakpoint, it does get hit, however Step In/Over and Continue do not work, and the test never finishes. Even if I set two break points, continuing won't hit the second. If I debug a test without a breakpoint, it finishes fine.
Also, often and intermittently, when I try to debug a test by setting a break point, I can't evaluate the contents of variables, but instead see this message:
Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation.
I am using Visual Studio 2010.
Please let me know if you have any ideas of what to look at... I have scoured the web, but without any luck.
Happy to provide further information if needed.
EDIT - Example of method
Test:
[Test]
public void OneRowAddedToSourceData() {
//Factory just returns System.Data.DataTable with correct columns.
var sourceData = new DataTableContainerFactory().GetTargetTableContainer(DataTypeNames.EventSharedEnd);
//GetRow just returns a populated row.
var row = GetRow(sourceData, 123456, 123,60, 31);
sourceData.DataTable.Rows.Add(row);
Assert.AreEqual(1, sourceData.DataTable.Rows.Count);
}
When I set a break point on the Assert statement, and try to evaluate the data table I get this problem.
UPDATE 2!
So, I have narrowed this problem down to Resharper Debugging. I changed a test class to MSTest rather than NUnit, but still got both the above problems when debugging with Resharper. However, when I ran the tests with the built in VS MSTest test runner, ALL the problems had gone!
Now I much prefer using NUnit and Resharper, so I would be very happy if someone could point me at a setting that will allow Resharper to debug properly!
I have a possible solution, albeit with a caveat. Did some searching and ran across this blog item. It suggests turning off Enable property evaluation and other implicit function calls from Tools->Options->Debugging->General. I turned it off and I can now go into items that previously caused this problem.
The caveat is that all the properties you're used to seeing automatically evaluated are now not being shown. Instead it states Implicit function evaluation is turned off by user. All you need to do is hit the Refresh button on a property and you can see the value, but I haven't decided whether this is a trade-off I'm willing to make.
I've found de way to solve this problem!
Check the option DEBUG->OPTIONS AND SETTINGS->GENERAL->ENABLE PROPERTY EVALUATION AND OTHER IMPLICIT FUNCTION CALLS and uncheck the option Call string-conversion function on objects in variable windows
This worked to me!
I am getting the following type mismatch error on the following
IF obj.propery THEN
...
END IF
the code I am using is on visual source safe and when other developers run the same project the code runs with no error. The property is actually a string which is where the problem could be. When I debug and test the property i.e.
?obj.propery = True
no errors are thrown which is a bit strange. If I place the cursor over the property it says "True". I have done a bit of searching on the matter and have found that this may have something to do with OPTION STRICT, however I have the same version of the code as the other developers and OPTION STRICT is not OFF, it hasn't been altered in the code at all. Are there any other settings that could affect this execution of code at run time?
It strikes me that there could be an entirely different reason for your Type Mismatch error, especially as you are accessing an object property. I've experienced this error when I have, for some reason, been pointing at a different DLL to that registered. You will find with VB that it registers a DLL "on the fly" when you build it, so you may end up accessing the code somewhere that you did not expect. This may not be the problem in your case, but it is worth exploring.
This was nothing to do with VB6, it was to do with XP Mode and using my user account from another domain as opposed to XPMUser. When I use XPMUser the application runs this is very odd and I am not sure why this is. If anyone has the reason I would love to hear.
So you are sure this is not the case of a boolean being Vrai?
I'd be inclined to be more explicit in your IF condition
IF isempty(obj.property) = false AND isnull(obj.property) = false
BUT
it would be prudent to check that obj isn't null first, before you start accessing its properties....