Addin-Manager + Multiple/ Support Dll's

[mertens3d]

I am able to get my primary dll to update after rebuilding with the AIM, but support dll's do not.

Is this the same behavior others see?

Has anyone found a solution to using the AIM with multiple Dll's?

[matthew_taylor]

Hi Gregory,

I sometimes get 'oddness' happening.

Cleaning and rebuilding the solution tends to clear it up.

Sometimes I go to C:\Users\<login>\AppData\Local\Temp\RevitAddins\ and delete everything...if all else fails.

-Matt

[mertens3d]

Yup, tried cleans, rebuilds and small animal sacrifices all with no success. 

On your end are you typically able to get the AIM to update your support Dll's?

Does it do it automatically or do you have to do something special?

I suppose I should do an experiment with a fresh project and two simple dll's.

If that works then it indicates that there is something amuck with my real code.

I have tried deleting the temp folder stuff, and if i remember right it wouldn't let me or it ignored it. (I'm not able to check right now).

I also think that after a new build, the AIM creates a new folder with my main Dll, but that folder does not contain the support Dll's. Instead it seems to be referencing the older folder.

Oh, also, my AIM claims to be from 2014. Yours too? I'm almost positive I got it from the 2016 SDK. I suppose it just means that they have not updated since then.

Thanks for the feedback.

[matthew_taylor]

No problem.

Yes, I'm using the 2014 version. There are bugs, but at least I know what they are. (I don't count your issue amongst them, though I'm sure I've had very similar issues in the past.)

I have each of my projects loaded into the solution when they are referenced by another project in that solution. I have these references (and only these) set as 'copy local'.

You're best to check these things, then start debugging with a new solution if you're still having issues. That way you can at least share it for debugging purposes!

p.s. You'll need to shut down all Revit before cleaning out that folder (if I remember correctly).

-Matt

[mertens3d]

Thanks Matthew, I'll do some experimenting tonight and see what happens. 

At least it's nice to know that it should or can work.

[mertens3d]

Did an experiment with no success.

Can you help me out some more?

Attached is a tiny vs solution with two projects.

When I build the solution and load the 'Main Project' dll into Revit with AIM and run it I get the message boxes as expected.

But when I make a change to the message box in the 'SupportB' project and rebuild, that change is not realized when I run with AIM.

f I restart Revit it is.

Do you get the same thing with the attached solution?

[matthew_taylor]

Hi Gregory,

Sorry to say that your sample solution worked completely as expected, with none of the issues you mentioned. (I followed your method.)

Perhaps there is another solution or dll causing interference?

Try renaming these folders before starting Revit. That should rule out most things:

C:\Users\<login>\AppData\Roaming\Autodesk\Revit\Addins\2016\

C:\ProgramData\Autodesk\Revit\Addins\2016\ - you'll want to create another one with just the addinmanager in it though... **

C:\ProgramData\Autodesk\ApplicationPlugins\

A few things I though of that may be causing grief:

• The example projects weren't built to .NET 4.5.
• Did you place the AIM files and .addin in the position marked with ** above? (As opposed to a local user folder.)
• I'm sure you know that if you rename a command you need to reload the .dll in the AIM for it to appear. The amount of times I've absentmindedly renamed a command then tried to debug it...!)
• Are your solutions on a local drive?

Let me know how you get on.

-Matt

[mertens3d]

good. good. No sorry's. We're narrowing it down.

Renamed both revit add-in folders to *-good

• started revit to confirm that there were no add-ins loading
• changed the roaming one back to 2016. The only thing in there is AIM
• Same bad behavior
• changed back to 4.5, same

I had it as 4.5 but switched to 4.6x to see if that changed anything.

My solution is on a local drive, but it is a VM.

other Stats

Windows7  64bit - all updates, legal

Workgroup (because it's a VM and not joined to the domain)

running in virtual box - latest (a possible, but unlikely candidate)

Revit 2016 (I need to check which service pack)

Visual Studio Ultimate 2013 with various extensions (lovin' on Resharper)

Plenty of hard drive space available

10 gb ram

solid state drive on the physical computer, checked as solid state in virtual box

I'll do more experimenting this evening.

[matthew_taylor]

Your setup (minus the VM) is very similar to mine.

Mine differs thus:

VS Pro 2013. (Loving Resharper also!)

No VM.

No Virtual Box.

It has worked fine for all Revit 2016 service packs.

I'd hazard a guess that it's the VM fogging things up. Check to see if the non-updating file is locked. (Right-click & Properties.)

Have you looked at the Revit journal to see if anything is reported?

Have you checked that the linked project is actually getting rebuilt? And copied local?

[mertens3d]

SOLVED!

I was looking into some more of your suggestions and decided to change the version of my support DLL.Suddenly cats and dogs were living together and my code showed changes.

Since it would be a pain to change the version every time I built, I implemented some auto versioning via ms magic in my AssemblyInfo.cs

// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("2016.07.*")]
[assembly: AssemblyFileVersion("2016.07.*")]

Matthew, thank you so much for your help on this. I owe you either a beer or ice cream. Your choice.

[matthew_taylor]

Glad you got it sorted, Gregory.

I'm pretty sure I've used one of your hatch macros at some point, so let's call it even. 😉

But hit me up for a beer if you're ever in London!

[mertens3d]

I wonder why you don't have to change the version, but I do. Hmmmm...

[matthew_taylor]

I was wondering the same thing!

I specify the version manually in my assemblies so I can't be much help.

Have you added your assemblies to the Global Assembly Cache (GAC)?

Have you heard of the 'Specific Version' property for references? I wonder whether that's affecting something.

Try putting an identical version in manually and see if the issue goes away.

[mastjaso]

@matthew_taylor@mertens3dHey guys I was wondering if this was still the case or if you've found any better solutions / fixes to this issue? I'm starting to build out libraries of tools which are stored in separate projects and it's starting to slow down development quite a bit to constantly update multiple assemblyinfo version numbers for every build.

Or @mertens3d could you shed any more light on the autoversioning you use to avoid this?

[mertens3d]

I haven't had time to figure out where it's going wrong.

If I did, I would create a simple multi-project solutions and verify that it requires a rebuild prior to attaching.

My current work flow, if i want to attach to process, is to do a rebuild and then attach. I only get one chance at this. After it has run once, it requires a rebuild.

It would be great if they open sourced AIM so that we could look at how it works and either fix it, or come up with a better work around.

As a partial productivity work around, I have several an extra build config (in addition to debug and release). That config only builds the projects that I am interested in stepping through. That helps...a little.

As far as the assembly version, I have played with using dynamic and static versions and neither seem to fix the problem. 

[mastjaso]

Ah, thank you @mertens3d, I guess I will have to continue manually changing version numbers (and I noticed the same odd behaviour about attaching the debugging process).

@jeremy_tammikCan we submit this Add-In Manager support dll issue as an official ticket for Autodesk to address? It does greatly slow development.

If the AIM is outside the scope of what Autodesk will support and fix (or support and fix in a timely manner) can it be open sourced so that the developer community can help address our issues with it?

[mertens3d]

@mastjaso

Oh...I may be brain farting a little and have forgotten about the diff static version number working.

Here is what I have done for static

All of the assemblyInfo.cs files has this.

[assembly: AssemblyVersion(mertens3d.hatch22.xxx.Constants.CurrentRelease)]

then in the xxx assemply (that all of the diff projects can reference)

    public class Constants
    {
        private const string ReleasePrefix = "2017.1009.";
 
#if DEBUG
 
        public const string CurrentRelease = ReleasePrefix + "0";
#else
        public const string CurrentRelease = ReleasePrefix + "*";
#endif
        }

I think I may have been then just changing the ReleasePrefix and then doing a new build (no rebuild). I'll need to try that again tonight.

[jeremytammik]

Dear @mastjaso,

Thank you for your request.

What exact issue would you like to report?

The development team requires clear and succinct descriptions of:

• A short exact description of what you are trying to achieve.
• The behaviour you observe versus what you expect, and why this is a problem.
• A complete yet minimal Revit sample model to run a test in.
• A complete yet minimal macro embedded in the sample model or Visual Studio solution with add-in manifest that can be compiled, loaded, run and debugged with a single click to analyse its behaviour live in the sample model.
• Detailed step-by-step instructions for reproducing the issue, e.g. which element to pick, what command to launch etc.

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

Cheers,

Jeremy

[matthew_taylor]

Hi Jeremy,

I've run into this frustrating problem again (using the version from the 2019 beta SDK), so here goes:

1. A short exact description of what you are trying to achieve. Have the addin manager properly load all latest support assemblies.
2. The behaviour you observe versus what you expect, and why this is a problem. Changes to support assemblies are not always loaded into memory. I have checked the C:\Users\<login>\AppData\Local\Temp\RevitAddins\<AssemblyName>-Executing-20180308_102930_9403\ folder, and the correct .dll files are there. I checked their content with DotPeek to confirm this. I wonder if the single C:\Users\<login>\AppData\Local\Temp\RevitAddins\<AssemblyName>-Parsing-<earlier time in day - first use?>\ folder with the main and support assemblies in is causing the issue?
3. A complete yet minimal Revit sample model to run a test in. An intermittent issue. Honestly, if I could work out how to reproduce it, I could fix it.
4. A complete yet minimal macro embedded in the sample model or Visual Studio solution with add-in manifest that can be compiled, loaded, run and debugged with a single click to analyse its behaviour live in the sample model. This is not relevant. Any Visual Studio solution with a project you are debugging, and another support project loaded into the solution and referenced in the debugging project. No IExternalApplication's, no .addin manifests.
5. Detailed step-by-step instructions for reproducing the issue, e.g. which element to pick, what command to launch etc.
   1. Run a simple add-in via the Add-in Manager (Manual Mode). The class implementing IExternalCommand should have a call to a function (*) in the support project.
   2. Change the (*) function.
   3. Re-run the add-in using 'Add-in Manager (Manual Mode)' or 'Add-in Manager (Manual Mode, Faceless)'. 
   4. The changes to (*) are not reflected, because an older version of the assembly is loaded into memory.

Frankly Jeremy, if the development team can't be bothered looking into this issue, then open source it so we can do it ourselves. Can you put some solid pressure on the development team? Yes, we know that the next version is due out. Kinda why we need this sorted sooner than later.

PRETTY PLEASE.

Best regards,

[jeremytammik]

Dear Matt,

Thank you for reopening this discussion and sorry to hear it is still causing pain.

I logged the issue REVIT-128489 [Revit API SDK add-in manager does not update modified support DLLs unless version number changes - open source it? -- 13857937]  with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

This issue is important to me. What can I do to help?

This issue needs to be assessed by our engineering team and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

• Impact on your application and/or your development.
• The number of users affected.
• The potential revenue impact to you.
• The potential revenue impact to Autodesk.
• Realistic timescale over which a fix would help you.
• In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

Cheers,

Jeremy