Working on mac? about weaver HOT 10 CLOSED

Hey HalfVoxel,

I personally don't own a mac and I can't use a mac from the office so I am unable to test it :(. The one thing off the top of my head is that I know Unity does not copy the Unity assemblies from the installation folder into the resources folder This might be causing the issue.

Are you seeing any errors in the console or any logs in the Weaver Console (the one on the scriptable object)?

Also what version of Unity are you currently rocking?

If my assumption is right you might see something along the lines of 'Unable to resolve assembly'.

from weaver.

Hi, thanks for getting back to me :)

Okay.

I know Unity does not copy the Unity assemblies from the installation folder into the resources
folder

Not quite sure which installation and resources folder you mean here. The resources folder in a standalone build?

Are you seeing any errors in the console or any logs in the Weaver Console (the one on the scriptable object)?

Nope, and not in the Unity editor log either. Rewriting the dll files seems to work perfectly.
Unity seems to reload it sometimes, but not always. I really hope this is not a race condition... that would be horrible to debug.

Also what version of Unity are you currently rocking?

I'm currently at 2017.1.1f1 as that's what I had installed. So the beforeAssemblyReload callback does exist on this version.

If my assumption is right you might see something along the lines of 'Unable to resolve assembly'.

Not anywhere where I can see. The strange thing is that Unity can load the assembly sometimes, it just doesn't pick up on the changes if I modify scripts after that (even though the rewrite does run).

from weaver.

No worries!

Damn, I was hoping the logs would guide the way. Could you post a screen shot of the log?

There is a few points in where Weaver normally fails.

Assemblies can't be resolved

This one has a lot of logging (because I broke this a bunch during development). We know this is not the case because there are not logs or exceptions (Cecil tosses these like there is no tomorrow).

Weaving not happening

Maybe the changes are not being written to disk correctly or something is failing during weaving. If you open them with MonoDevelop or any other decompiler can you see the changes? If you don't see the changes that is the bug right there.

Assemblies not being loaded

I use [beforeAssemblyReload](https://docs.unity3d.com/ScriptReference/AssemblyReloadEvents.html) callback to change the assemblies before Unity tries to load them. If this callback is not working you would not see the effects of the weaving after you make changes. However if you hit play you would.
Could you enter playmode and see if the changes take effect?

Invalid IL is being generated

This one is a bit harder to find because with Cecil you can write horribly broken IL. I don't have any checks for this because I don't know how to do that yet. Normally Unity tosses some errors about not being able to read the assembly. I don't think this is it because you say there is no errors.

Thanks for the help!

from weaver.

I'll get you the log soon, but I'll answer some of the questions first.

Weaving not happening
I have verified that the correct assemblies are written to disk. If I open them in Monodevelop the changes are there. I also used a tracer to check the disk io that Unity does, and Unity does seem to open the .dll files after they have been rewritten.

Assemblies not being loaded
This callback seems to be working. Entering play mode is what I use to test the changes with, and it's not being picked up there either.

Invalid IL is being generated
This is with your extensions without any significant changes. Also note that it does manage to load the assemblies sometimes, but not always. And the only thing I change is something like Debug.Log("Test1") to Debug.Log("Test2") and check if Unity pick up the changes.

I also tried adding a call to AssetDatabase.Refresh after the assemblies were saved, but that does not appear to have helped at first glance.

Also. Do you happen to know a nice way to get a textual representation of a dll file or some easier way to compare two dll files? I tried to diff the original and modified dll files but they are in a binary format and the diff did not produce anything useful.

from weaver.

Well that is some helpful information but I can't think of what might be happening. The dlls are there, they are modified, but are never loaded after the first time.

The only thing left would be that Unity refuses to reload the new assembly for some reason. This makes sense that when you close Unity and reopen it you see the changes.

I will have to try to debug this on mac.

Quick question, are you having Weaver modify one of the generated assemblies ie. Assembly-CSharp?

As for an easy way to get a diff on an assembly I do not have one. I personally just look up the changes with ILSpy to validate that they happened. A diff tool would be so much better.

from weaver.

Yeah it's really strange. I will try to experiment a bit more on my end.
My current guesses are that it is either a race condition, that the dll is invalid for some reason (likely some metadata) or that somehow assemblies are being locked (like using Unity's LockReloadAssemblies) in some way.

Alternatively Unity could be verifying some hash of the dll files, but that seems unlikely.

from weaver.

Quick question, are you having Weaver modify one of the generated assemblies ie. Assembly-CSharp?

Yes. That dll only.

from weaver.

Yeah it would seem super odd if they were checking some sort of hash just for mac. I will take a look at the source that Unity released and see if there is any difference between mac and windows for any functions that I am using.

from weaver.

Hey guys, just grabbed this and am testing in a mac environment. It looks to be working well so far. The provided MethodTimer and PropertyChanged components are functioning, in both editor and builds.

@HalfVoxel The issue with the assemblies not being reloaded by Unity could be caused if you are importing types into a module that are defined in that module. Cecil does a safety check for this if you import a TypeReference, but not if you import a System.Type. Any line like Module.Import(typeof(SomeTypeDefinedInModule)) could be the culprit. I've run into this before and this turned out to be the issue. Cheers!

from weaver.

Thanks metzsg!

I was unaware of that, I should most likely go around an update how I do the demos.

I started Weaver to give me a chance to learn more about Cecil and how to use it. So I enjoy any feedback I get.

Cheers,
Byron

from weaver.