OK, thanks. Well those two lines of code you mentioned there are not really for 'updating' the assembly specifically. What I was talking about was something like one of the following:
(used at/near end of rule, for immediate update)
iLogicVb.DocumentUpdate
or ILowLevelSupport.UpdateWhenDone Property (used at/near start of rule, to cause update when rule finishes)
iLogicVb.UpdateWhenDone = True
or Document.Update (where the variable 'oDoc' represents the Document object you are working with)
oDoc.Update()
or Document.Update2([AcceptErrorsAndContinue] As Boolean)
oDoc.Update(True) 'True means accept errors and continue
or Document.Rebuild()
oDoc.Rebuild()
or Document.Rebuild2([AcceptErrorsAndContinue] As Boolean)
oDoc.Rebuild2(True) 'True means accept errors and continue
I usually include something similar to one of those lines of code above at/near the end of most of my iLogic rules, to make sure that the document that the rule is making changes to gets updated after the changes have been made. However, it sounds like you have already tried the Update and Rebuild All buttons in the user interface after running your rules, and they do not work to cause the components to move to their proper locations. So, something must be going on.
From your last answer above, it sounds like you do have the 'Defer Updates' setting turned on. As you may know, that prevents components from moving, even after constraint value modifications, until you manually perform a document update. Then the components will move to the locations they are supposed to be, according to the constraints. This sounds very much like what you are describing, but it sounds like some are still not moving, even after a regular Update or Rebuild. That is very odd. Are you using 'skeletal' modeling techniques? Do some of your model files have other models 'derived' into them? If so, are some of those models that have derived models in them, also derived into other models? If so, the 'update system' may be loosing track of the second layer of 'derived in' stuff, not sure.
Wesley Crihfield

(Not an Autodesk Employee)