Announcement

Collapse
No announcement yet.

Plugins on the network?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Plugins on the network?

    I am looking at automating plug-in install, and as with so many things, what I as an IT person want to do is put the plug-in on the network and have everyone share it. But what the readme always says is install locally. Just wondering if anyone has played around with network resourced dlls like this. Is there a limit on the number of users who can access? Or does each user just load the dll to local RAM anyway, and there is no reason not to do this?

    Any real world experience is greatly appreciated.

    Thanks!
    Gordon
    Pragmatic Praxis

    #2
    And perhaps even more urgent, has anyone gotten the ADNPlugin-RoomRenumbering plugin to work in 2012 at all? Even doing the entire install manually I get an error when I try to run. Given that it is an ADN freebee I expect no support out of Autodesk, so hopefully someone here can at least verify they have it running so I can start looking for what I am doing wrong.

    Thanks!
    Gordon
    Pragmatic Praxis

    Comment


      #3
      Rod Howarth put up some code to help with this :

      http://blog.rodhowarth.com/2011/05/r...ins-to-be.html
      bim cad tech com

      Comment


        #4
        Jose, thanks for that. I may look at adding that to my install script.

        On a related note, it turns out that what was causing my addin to fail even when installed locally was some fun new security in Windows 7. Scott Sheppard & Kean Walmsley hooked me up with the good info.

        Per Kean: "Many of the 2012 family of products use version 4 of the .NET Framework. .NET 4.0 implements slightly more stringent security than prior versions of the framework: if a DLL is suspected as having been downloaded from the web – as is clearly the case with our “Plugins of the Month” – the .NET 4.0 runtime will treat that DLL as if it has been loaded from a network share. And as many of you have found out, from trying to load DLLs from network shares, this results in a reduced set of privileges on the local machine, which can often result in a load error such as this one:

        Code:
        Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly...
        The solution is straightforward: you simply need to “Unblock” the DLL by right-clicking on it in Explorer and selecting “Properties” and “Unblock”. It’s actually better to do this for the .ZIP prior to extracting the contents, as this makes sure all files contained in the archive are unblocked."

        I followed this procedure on my copies of the files on the network, and now when I install locally everything works as expected. With Jose's info I should then be able to get it to work with only the manifest file getting copied, which is nice because updating to a new version of the dll just means coying it once to the network, no need to copy to each machine.

        Sweet!

        Gordon
        Attached Files
        Pragmatic Praxis

        Comment


          #5
          Ive got a few plugins for 2012 that wont initialize at all unless Revit is right click> Run as Administrator'ed.

          Sigh....

          Although to ask an IT newb question, whats the benny of having the actual DLL's on the network? If you abandoned xml and are heading back to a VBS solution, why not just copy everything locally with the VBS? The .addin files are now in a local User directory anyway, so you cant avoid it (i dont think?).
          Aaron "selfish AND petulant" Maller |P A R A L L A X T E A M | Practice Technology Implementation
          @Web | @Twitter | @LinkedIn | @Email

          Comment


            #6
            Aaron,
            I would try the unblock trick on those dlls, and the addin manifests too. I didn't try to Run Revit with elevated privaledges, but I think it might have worked.

            As for networked dlls, when everyone is just running the one dll off the network, if the addin gets an update I just drop the new version of the dll in place, and everyone has the newest stuff, I get :beer:. Otherwise I have to go to each machine and run an install script. Not the end of the world eaither way, and I don't even know that many addins get an update all that often. But Kiwicodes sure does a good job, so maybe updating dlls will be a real task to consider automating.

            Gordon
            Pragmatic Praxis

            Comment


              #7
              Running as local admin wont work in some companies policies. That sucks.
              -Alex Cunningham

              Comment

              Related Topics

              Collapse

              Working...
              X