search

DynamoDS / Dynamo

Open Source Graphical Programming for Design
https://dynamobim.org
Other
1.72k stars 632 forks source link

Unable to Publish Version of Package with Dynamo 1.0, Revit 2015/16 #6565

Closed archinate closed 8 years ago

archinate commented 8 years ago

Dynamo version

Dynamo -- Build 1.0.0.1180 with Revit 2015 and Revit 2016

Operating system

Windows 10

What did you do?

Updated my packages and attempted to "Publish Version..." through Revit 2015 and 2016. I verified that I am using the correct A360 account etc.

image

What did you expect to see?

I expected to see the Package menu that lets me publish a version of my package.

What did you see instead?

After accepting the package manager terms of service, no menu or message appears. Package version is not published.

ksobon commented 8 years ago

@archinate are you trying to publish from a Dynamo Sandbox? I have noticed that this feature is disabled in Sandbox and even if your package is not dependant on Revit you can only publish a package by launching Dynamo from Revit.

ikeough commented 8 years ago

@kronz FYI

archinate commented 8 years ago

@ksobon No, I am trying to publish a version out of Revit 2015 or 2016

archinate commented 8 years ago

@ikeough @kronz Just to add to this one... It appears publishing is working as expected from Revit 2017. Just not 2016 or 2015.

kronz commented 8 years ago

@archinate . Without having Dynamo in the mix, If I have Revit 2016 and Revit 2017 open, and I sign into a360, I immediately get signed back out! If I close r2017 and try again in r2016, the sign in sticks. You?

kronz commented 8 years ago

@archinate ok, taking the weird Revit 2016 and Revit 2017 open at the same time issue out of the equation, I can reproduce something like what you are describing. However, what I'm seeing is that I can't publish from "publish this custom node" if I'm adding a new version, but I can for a fresh package. Also, I CAN publish from the "Publish Version . . ." dialog, and the behavior is the same for me in both Revit 2016 and 2017.

archinate commented 8 years ago

@kronz Still not sure why, but removing my custom Trello add-in (like in issue #6556) fixes this issue and I can Publish Version as usual. Installing the addin again prevents me from publishing.

With add-in installed this is what happens every time...

Without the add-in...

ikeough commented 8 years ago

@archinate The Package Manager Terms of Use is being presented every time because it's never able to cache the fact that you accepted the TOU previously. This value is saved on your User in the package manager database. There is some error in communicating with the PM server. Can we get a version of your Trello add-in to test?

archinate commented 8 years ago

@ikeough I sent it along to @zach and @jnealb... I will forward over to you via e-mail.

ikeough commented 8 years ago

@archinate I believe this is a clash in the version of an assembly. RestSharp, which we use to communicate with the package manager, is also used by your addin. I'm guessing that this problem is happening because we're trying to load two different versions of RestSharp in to the AppDomain. When this happens, types cannot be resolved correctly. We are probably just failing silently to create a rest client.

Unfortunately, I'm not sure what we can do exactly. We could synchronize our versions of RestSharp in the hope that using the same version will avoid these kinds failures to resolve types. But that will break as soon as one of us decides we want to upgrade RestSharp. I think we need to find a way to specify that we should be using a specific version of RestSharp and allow it to load multiple versions into the AppDomain if yours specifies differently.

All of this is, of course, speculation, until we load up your addin and see what's happening. But it sounds pretty close to what I've seen before.

mjkkirschner commented 8 years ago

@ikeough http://adndevblog.typepad.com/aec/2012/06/loading-multiple-versions-of-the-same-dll-used-in-revit-plug-ins.html

apparently this can be done to an existing dll as well, or we could build restsharp from source...

ikeough commented 8 years ago

Strong-naming RestSharp breaks our ability to reference it using NuGet.

kronz commented 8 years ago

@ikeough is there anything for us to do here? With the restart of the the server, we aren't having the earlier identified issues associated with systems that don't have the RestSharp conflict. Also seems like the original bug isn't accurate, should we cloase this and open a more specific description?

ikeough commented 8 years ago

@kronz A server restart was required? If that did anything, it wasn't related to this issue. Can you give me more details?

Strong naming an assembly is going to add a painful step to our process. We're trying to get rid of binaries in our repo, not add them back in, and strong naming would require that we keep a copy of RestSharp in our repo, and that whenever we wanted to update that dlls, we'd have to run the strong naming tool on it. That sucks. We could ask @archinate nicely to update to the newest version of RestSharp, to align with us, then add this as a known issue on the FAQ, and possibly provided a better exception method with missing method exceptions like "Dynamo cannot find a method that it requires to execute, it could be that there's a conflict with another version of an assembly loaded in the application."

Apropos of our conversation of the other day about crash bugs, we should isolate the package manager fully as an extension, and check while loading the extension whether the correct version of RestSharp is being used.

kronz commented 8 years ago

@ikeough there were issues around changing version versus new uploads where (with machines having no Trello plug in) they seemed to be irregularly failing silently. @mjkkirschner and @QilongTang suspected it had to do with responsiveness of the server, and it seems that those issues have disappeared over since the server was restarted.

mjkkirschner commented 8 years ago

Something we discussed today was checking all currently loaded assemblies and comparing these to a list of our usual required assemblies on start of dynamoRevit addin, if an older version is found we can alert the user that an incompatible addin is installed.

On May 5, 2016, at 11:15 PM, Zach Kron notifications@github.com wrote:

@ikeough there were issues around changing version versus new uploads where (with machines having no Trello plug in) they seemed to be irregularly failing silently. @mjkkirschner and @QilongTang suspected it had to do with responsiveness of the server, and it seems that those issues have disappeared over since the server was restarted.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

archinate commented 8 years ago

@ikeough and @kronz I'll check out what it means to use the newest version of RestSharp. It is actually dependency that is part of another library I am using so I don't know what affect it might have on that library. Happy to look into this as a near term solution.

It just seems a bit odd that Dynamo functionality would have a conflict with an unrelated addin in Revit, no? The addin I am developing isn't meant for Dynamo users at all.

So this also begs the question... what unforeseen conflicts might arise for Revit addin developers to avoid potential problems for Dynamo users? It seems like a new design/development criteria since Dynamo is now shipping with Revit and there may be other libraries, other than RestSharp, that may create similar issues.

-Nate

ikeough commented 8 years ago

@archinate This is not a problem specific to Dynamo. Revit loads all addins into the Revit AppDomain (or one app domain for all addins - we should check). If any two addins try to load different versions of an assembly, and those versions are different in a way that could cause one of the addins to fail, with a MissingMethodException for instance, you'll see this.

Your second question is something for us to consider. We need to ensure that Dynamo for Revit always works. If this means strong-naming all of the assemblies that we use, then this is something we need to investigate.

riteshchandawar commented 8 years ago

@archinate @ikeough @jnealb Internal issue has been closed with verified status.

@archinate Can you please confirm it at your end?

Thanks, Ritesh

ikeough commented 8 years ago

@archinate See @sm6srw's comments on https://github.com/DynamoDS/DynamoRevit/pull/988#issuecomment-218251554

archinate commented 8 years ago

@ikeough Understood. I am in touch with a few app developers that are having similar issues with their tools and dependent libraries conflicting with Dynamo and we may have a few solutions to try. There are more folks than just me using RestSharp, etc in their tools so it goes beyond "Nate's crazy alpha Trello tool"! :)

In looking at what ships with Dynamo, there are many common libs in there that could potentially create similar conflicts (Newtonsoft, for example...which I use in many of my tools). I'll let you all know if we come up with any solutions.

kronz commented 8 years ago

There are a couple of issues in this thread. I think the last is covered by https://github.com/DynamoDS/DynamoRevit/pull/988