LINQ query filter families

[Moshe-A]

Hey Guys,

Suddenly my VS 2015 DEBUG stopped working. found on the web this solution...to disable 'Require source file to exactly match the original version

(Debug\Options\Debugging\General) and the DEBUG came to life.

but now i am facing another problem...at debugging mode the code stops at line 181 to make the filter, the return value is weird, although listfamilys.Count return 0 (that's good cause there is no family inside and i want it to load the family) the compiler skips line 184 and jump to 187 and a grayed '< 1ms elapsed'  note popup there.

i do not know if the 2 issues are related, just thought i should mention them if they do?!)

any one seen this? 

workaround?

thanks

Moshe

[Moshe-A]

Hey Guys,

Suddenly my VS 2015 DEBUG stopped working. found on the web this solution...to disable 'Require source file to exactly match the original version

(Debug\Options\Debugging\General) and the DEBUG came to life.

but now i am facing another problem...at debugging mode the code stops at line 181 to make the filter, the return value is weird, although listfamilys.Count return 0 (that's good cause there is no family inside and i want it to load the family) the compiler skips line 184 and jump to 187 and a grayed '< 1ms elapsed'  note popup there.

i do not know if the 2 issues are related, just thought i should mention them if they do?!)

any one seen this? 

workaround?

thanks

Moshe

[RPTHOMAS108 · Accepted solution]

In the past working with dynamo I had to attach to process and the source wasn't the same as the dll file. I got similar confusing behaviour but then when I looked at the dll it was evident it was skipping lines that didn't exist in the old dll. You get similar behaviour when you switch configurations i.e. you have a release dll which is new but you are asking Revit to use the one in debug.

I don't know why that option exists but there does not seem to be a valid reason to use it, as far as the Revit API is concerned. Perhaps the dll file that was compiled previously is somehow being prevented from being overwritten and that lead to you original problem? Now I believe you are effectively asking the debug environment not to bother writing a new assembly (if it can't) and try to match symbols in the new source. Perhaps?

[RPTHOMAS108 · Accepted solution]

In the past working with dynamo I had to attach to process and the source wasn't the same as the dll file. I got similar confusing behaviour but then when I looked at the dll it was evident it was skipping lines that didn't exist in the old dll. You get similar behaviour when you switch configurations i.e. you have a release dll which is new but you are asking Revit to use the one in debug.

I don't know why that option exists but there does not seem to be a valid reason to use it, as far as the Revit API is concerned. Perhaps the dll file that was compiled previously is somehow being prevented from being overwritten and that lead to you original problem? Now I believe you are effectively asking the debug environment not to bother writing a new assembly (if it can't) and try to match symbols in the new source. Perhaps?

[Moshe-A]

Thomas,

Marvelous, although i did not build to release but i did change the cpu configuration to x64 (the cause for that was DEBUG refuse to work)

and the manifest file still address the old dll the DEBUG now works but the grey notes still exist - are they a problem?

thanks

Moshe

[Moshe-A]

Thomas,

Marvelous, although i did not build to release but i did change the cpu configuration to x64 (the cause for that was DEBUG refuse to work)

and the manifest file still address the old dll the DEBUG now works but the grey notes still exist - are they a problem?

thanks

Moshe