Revit API Forum
Welcome to Autodesk’s Revit API Forums. Share your knowledge, ask questions, and explore popular Revit API topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Use relative paths (%appdata%) in .addin file

14 REPLIES 14
SOLVED
Reply
Message 1 of 15
ATassera
2116 Views, 14 Replies

Use relative paths (%appdata%) in .addin file

Hey everyone,

 

Is it possible to use a relative path, such as %appdata% in the Assembly section of the addin file?

 

I am developing this plugin that will be deployed to other people in the company, and the DLLs will live somewhere in C:\Users\<USERNAME>\AppData\Roaming\NameOfFolder\... so writing the explicit path with the user name is not a real option. Normally in Windows you would use %appdata% but it doesn't seem to be working in the .addin.

 

Is there a way?

 

This is what I tried but isn't working:

<?xml version="1.0" encoding="utf-8"?>
<RevitAddIns>
 <AddIn Type="Application">
       <Name>Wb.ModelEstablishment.Revit</Name>
       <FullClassName>Wb.ModelEstablishment.Revit.Ribbon</FullClassName>
       <Text>Wb.ModelEstablishment.Revit</Text>
       <Description>Model Establishment</Description>
       <VisibilityMode>AlwaysVisible</VisibilityMode>
       <Assembly>%appdata%\folder\subfolder\Wb.ModelEstablishment.Revit.dll</Assembly>
       <AddInId>d06838e1-44e3-4c05-b9f1-f79ca101075c</AddInId>
    <VendorId>WB</VendorId>
    <VendorDescription>Woods Bagot</VendorDescription>
 </AddIn>
</RevitAddIns>

 

But if I use:

<Assembly>C:\Users\sydata\AppData\Roaming\folder\subfolder\Wb.ModelEstablishment.Revit.dll</Assembly>

it works fine.

14 REPLIES 14
Message 2 of 15
jeremy_tammik
in reply to: ATassera

Yes, it is definitely possible to use relative paths in the add-in manifest.

 

However, %appdata% is not a relative path.

 

That is a variable in an MS-DOS or Windows batch file, or possibly nowadays in a PowerShell script or something suchlike.

 

Revit add-in manifest files do not support variables, neither MS-DOS nor Windows nor Unix nor any other flavour.

 

You can read about what is and is not supported in manifest files in the Revit online help section on add-in registration:

 

https://help.autodesk.com/view/RVT/2021/ENU/?guid=Revit_API_Revit_API_Developers_Guide_Introduction_...

 

Jeremy Tammik, Developer Advocacy and Support, The Building Coder, Autodesk Developer Network, ADN Open
Message 3 of 15

... Look there for 'In a non-user-specific location in "application data"'...

Jeremy Tammik, Developer Advocacy and Support, The Building Coder, Autodesk Developer Network, ADN Open
Message 4 of 15
ATassera
in reply to: ATassera

Thanks for the reply @jeremy_tammik 

 

I have read the page you sent, but the whole 'user-specific' or 'non-user specific "application data"' talks about where to save the .addin file, not how to point to dlls placed in the %appdata% folder through the <Assembly> XML tag inside the .addin file.

 

The .addin file can be in the C:\Users\<user>\AppData\Roaming\Autodesk\Revit\Addins\... folder, that's not a problem. The problem is that the <Assemly> tag needs to point to C:\Users\<user>\AppData\Roaming\... and I don't know how to achieve that without using the absolute path. I can't write one specific addin file for every user in the office.

 

Does it make sense?

 

Thanks!

Message 5 of 15
jeremy_tammik
in reply to: ATassera

Dear Andrea,

 

Yes, absolutely, it makes perfect sense.

 

As said, the %appdata% variable that you are referring to is a Windows specific variable that is not understood or supported by the add-in manifest file.

 

One simple option I see for you is to (automatically) generate a user-specific add-in manifest for each user and place each one in the appropriate user-specific location.

 

Another possible approach would be to place one single add-in manifest file for all users into the system-wide global location, and then use other run-time criteria to determine whether or not to make individual add-in functionality and components available to each user on a case-by-case basis, e.g., using AvailabilityClassName.

 

I hope this clarifies and helps.

 

Looking forward to hearing how you end up solving this.

 

Cheers,

 

Jeremy

  

Jeremy Tammik, Developer Advocacy and Support, The Building Coder, Autodesk Developer Network, ADN Open
Message 6 of 15
jeremy_tammik
in reply to: ATassera

Oh, and another thing, much simpler:

 

I almost never use the add-in assembly DLL path at all.

 

I just place the add-in assembly DLL in the same location as the add-in manifest *.addin file, and then it is found without specifying any path at all.

 

If you are already placing the add-in manifest file in the user-specific location, why don't you just put the DLL in the same place?

 

Jeremy Tammik, Developer Advocacy and Support, The Building Coder, Autodesk Developer Network, ADN Open
Message 7 of 15
ATassera
in reply to: ATassera

Thanks @jeremy_tammik for clarifying. I get what you mean now!

 

Unfortunately the DLLs are in the %appdata% folder because they come through pyRevit and the repository gets pulled under %appdata%\pyRevit\Extensions\...

Usually pyRevit doesn't need addin files, but this is a linkbutton because I need things to happen at application level (like registering a dockable panel) so it needs to have an addin file to load the DLLs when the Revit application is loading. It's a bit more complex than usual.


We could maybe write a PowerShell script that moves those DLLs somewhere else, but it seems a bit convoluted.

 

Creating an automatic generator of the addin sounds interesting though. From the docs you posted I don't understand where that code would live though. It says that "It is intended for use from product installers and scripts". Does it mean something like a PowerShell script?

 

Thanks!

 

Andrea

Message 8 of 15
jeremy_tammik
in reply to: ATassera

You mean the RevitAddInUtility.dll?

  

The answer is Yes:

 

https://thebuildingcoder.typepad.com/blog/2010/04/revitaddinutility.html

 

 

Jeremy Tammik, Developer Advocacy and Support, The Building Coder, Autodesk Developer Network, ADN Open
Message 9 of 15
mastjaso
in reply to: ATassera

Hey @ATassera, I believe the answer you're looking for is to just use the relative path modifier for moving up a folder level "..\" there's no need to run a script at install just to get to a user's appdata folder. 

For instance, if I put my addin dlls under a different roaming folder like so:

mastjaso_0-1613584715895.png

then to access those dll files from my addin, I can simply use "..\" to navigate up to my roaming folder (in this case I'm navigating up 4 levels):

mastjaso_1-1613584771923.png

 

and when I launch Revit, you'll see that it's parsed the path correctly and will load the addin:

mastjaso_2-1613585027395.png

mastjaso_3-1613585211223.png


Also %appdata% is the specific notation that cmd.exe and other Windows utilities use to refer to the appdata environment variable, but environment variables are in no way Windows specific and are commonly used on all operating systems. Revit really should support the use of environment variables in these addin files.





Message 10 of 15
jeremy_tammik
in reply to: mastjaso

Great solution!

 

Nice and simple and direct and down-to-earth.

 

I already shared this thread on the blog for posterity, and I went and added your new solution as an addendum to that:

 

https://thebuildingcoder.typepad.com/blog/2021/02/addin-file-learning-python-and-ifcjs.html

 

Thank you!

  

Jeremy Tammik, Developer Advocacy and Support, The Building Coder, Autodesk Developer Network, ADN Open
Message 11 of 15
ATassera
in reply to: ATassera

Thanks @mastjaso for the answer! Great simple idea and yes, that would be a pretty good solution actually.

Only thing worth specifying is that the .addin file has to be in the AppData\Roaming\Autodesk\Revit\Addins\xxxx folder. It wouldn't work in case the .addin was in the ProgramData folder of course, as Revit checks both folders for addins when firing up.

 

Right now we still haven't made a final decision on which way to do this, but we're testing a solution where we use a folder that's outside of the %appdata% folder, because it should also be easier to access from Azure Pipelines. I'll keep you posted

Message 12 of 15
jeremy_tammik
in reply to: ATassera

Did you also see Joshua's suggestion in a comment on the blog post?

 

https://thebuildingcoder.typepad.com/blog/2021/02/addin-file-learning-python-and-ifcjs.html#comment-...

 

Looking forward to hearing what you decide to do.

  

Jeremy Tammik, Developer Advocacy and Support, The Building Coder, Autodesk Developer Network, ADN Open
Message 13 of 15
mastjaso
in reply to: ATassera

.. (double post, don't know how to delete)...

Message 14 of 15
mastjaso
in reply to: ATassera

Hmm, out of curiosity what do you mean by a folder outside of %appdata%, and why would it be easier using Azure Pipelines?

 

Just asking because we currently bundle all of our Revit applications into .msi installers using build scripts and such on Azure pipelines, and they all install with just user level permissions (no admin prompts), to a user's appdata folder, as well as a collection of dynamo nodes and packages that get installed to the user level public folder on the user's machine. I'd be happy to share our scripts / setup if it would help at all!

Message 15 of 15
ATassera
in reply to: ATassera

@mastjaso thanks a lot for the help and for being so open! Really appreciate the attitude.

 

We don't use .msi to deploy our internal tools. We we don't want ppl to have to close Revit and run an installer to update manually their tools every time we release new features/fixes (which can be quite frequent).

 

What we do instead is use pyRevit that grabs a BitBucket repository that contains all the necessary scripts and/or dlls and without closing Revit you have all the updated files.

And this is actually the reason why I needed to access %appdata% from the addin file. The repo that gets pulled by pyRevit lives under %appdata%\pyrevit\.... and all the dlls end up there.

 

The reason why I was saying that the other folder is easier to access from Azure is that that folder is in a server and I thought of accessing it with an Azure task Copy over SSH or something similar.

Anyway I changed my mind and I'm using Powershell in Azure to copy the files built by the pipeline in the repo and then a couple of git commands to push to the BitBucket repo. So I'm using the solution you suggested of going up 4 folders to access my %appdata%.

 

Thanks!

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Rail Community