Trying to use the Worker class.
When I debug my project, the app runs fine (threaded, of course).
If I try to build the app, I get two errors:
Can’t find a type with this name
This item does not exist
(nothing more, no line shown or keywords)
Both errors have this location:
, line 2
The various “Analyse” menu items don’t show these errors, so I can’t analyse each class separately.
Since these errors happen on build only, it feels obvious they are related to the Worker and its different implementation, but, beyond that, I’m puzzled on how to debug this.
Update: I’ve narrowed the issue down. The current state is this: if I remove the worker (and remove its references), I can build the project. As soon as I add a Worker (not even configuring it), building the project produces these errors.
Project corrupted. How fun…
That’s because the worker includes all your project items.
If there are any references in them which the worker can’t use or if there are any methods which are not console safe then you get the build errors.
Yes, I too went through Arnaud’s issue before figuring this out. In my case I just needed to include a module that the worker needed to register a plugin. Note, by the way, that if you also use the same plugin in the main app, you need to have separate registrations for each, as the console app otherwise has no idea of it.
That’s true, but it’s not my issue, I’m afraid.
In normal circumstances, Xojo reports a valid location and the offending line, highlighting the class/call that makes the problem. Double-clicking the error reveals the error in the IDE.
Here, the location is empty and there’s no line mentioned; Double-clicking doesn’t do anything.
I’m still thinking the project file is corrupted. Two days ago, my code worked fine; any item needed to be excluded was marked as non-console safe (unchecking the checkboxes for individual classes). ProjectItemsToIncludeAtAll was not used at all.
And yesterday, I made changes and realized it wouldn’t build anymore. Even by reverting to the state of yesterday, by deleting my changes, the issue remains.
These steps also make me thinking the project is corrupted:
I remove the Worker and the project builds fine.
Then, I add a dummy Worker and a dummy class (CTest). In the worker, I set ProjectItemsToInclude to “CTest” and nothing more. At this point, the project can’t be built anymore, even the worker having only CTest included and no other code.
Well, I have no clue as to what those items are, except than checking the whole project, since the compiler fails to target the part of code that makes the problem.
Yes, you may even make a complex project only by debugging, thinking it works, and when you finally decide to build, you realize the core of your project can’t work.
You’re right. I don’t know why I formatted it like a property in my reply…
Yes, that’s why I tried adding a dummy class and setting the “Project items to include” to that class, so I know the worker doesn’t include anything. And yet, I get a compile error at build time that way too. Which means my project is corrupted.
I’ve tried saving the project as XML. All was saved, except the worker (again a proof of corruption). Then, adding a worker to the XML version also makes this problem re-appearing.
At this point, I think I’ll have to redo the transition from the previous working version (before the worker existed) to the one using a worker all over again.
Not even counting how I feel worried about future project corruptions using workers…
No, I didn’t even referenced the class (no property, etc.). Just put the class name in “Project Items To Include” so that it’s not empty, but not use it at all otherwise.
Instantiating the class (thus adding a property for it) would be worse in proving the problem is project corruption and worker alone.
I too have to use real classes, but managed to strip down a temporary copy of the project where the worker can be empty for testing purposes.
If you have indeed encountered the same issue, I guess you’d get the same weird effect if you manage to remove existing workers and add a dummy one (in a temporary file, of course).
One other issue I ran into, was that the client’s code that I was refactoring was calling a couple of properties in App. Again, a no no for a console program–and yet again, something that misleadingly works in a debug run.
If you have indeed encountered the same issue, I guess you’d get the same weird effect if you manage to remove existing workers and add a dummy one (in a temporary file, of course).
Don’t know about that, but my issue was resolved when I had the light bulb moment that “blank means everything” (in other words, I RTFM). Then, as to those properties in App, I pass them to the worker, along with everything else, in xml.tostring.
