[Bug]: develop-4 branch only IOError: System.IO.IOException: Could not add reference to assembly pyRevitLabs.Emojis about pyrevit

[jmcouffin]

Since this is a breaking change, I suppose that we should revert back to having the dlls into the repository and only remove them on the develop branch - and we should discuss about the future of the pyrevit cli at the next online meeting!

bringing back the dlls into the master right now 😨 😄 👿
@sanzoghenzo

[sanzoghenzo]

great, I just sent you a DM on discourse, let me know if you need help

[sanzoghenzo]

Hi @acco-jpitts,
We introduced some changes and removed most of the dlls from the repository; I don't think it will be possible to switch branches anymore.
If you want to check new features or fixed done in the develop-4 branch, you're better off downloading and installing the WIP installers you can find in the actions section, such as this one

[acco-jpitts]

Hi @acco-jpitts, We introduced some changes and removed most of the dlls from the repository; I don't think it will be possible to switch branches anymore. If you want to check new features or fixed done in the develop-4 branch, you're better off downloading and installing the WIP installers you can find in the actions section, such as this one

pretty sure that is same WIP version installer I'm using.

pyRevit_CLI_4.8.15.24085_admin_signed.exe

Then cloning the repository while specifying the develop-4 branch using the CLI.

Or are you saying I can only use the direct installers and not CLI? I thought you couldn't specify a branch if its not a cloned repository?

[sanzoghenzo]

I may be wrong, but if you install the wip version the pyrevit-Master folder is already a snapshot of the develop-4 branch, with the added bonus that the dlls are compiled and shipped inside that folder.

@eirannejad have we broken the clones management by removing the dlls from the repository? Should we rethink the whole clones behavior?

[jmcouffin]

I haven't had any issue myself foing exactly that:

• WIP installer,
• then switching between dev-4 and dev-4 cloned branches.

No, I was wrong
Did not get the latest wip installer, but the one before the removal of the dlls

[sanzoghenzo]

Sorry, I should shut up and let the grown up talking, I don't even know how to switch clones 😅 - I will try to do it and see if I can reproduce.

In the meantime, just to be sure:

1. Install pyrevit using our standard installation script, but specify the develop-4 branch instead of master

What is your "standard installation script"? what does it do?

[acco-jpitts]

try the following installation script to reproduce the issue. Place both the bat file and the ps1 script file in the same folder as the pyRevit_CLI_4.8.15.24085_admin_signed.exe from the latest WIP release.

Also added the installation command for ndp48-devpak if its needed but commented out since I'm assuming you have this...

when "$condition = $True" at the top of the powershell script, pyrevit should load without issue.
when "$condition = $False" at the top of the powershell script, pyrevit will not load due to the dll's missing.

I'm assuming when you say "installer" you mean the non-CLI installer. This would not be ideal if future deployments could not be done using cloned repo.

Check the paths I'm using, as script will make sure these paths are clean before cloning pyrevit to it.

This is pretty close to my standard installation script, but with the toggle for testing the dev vs master added, and removal of my extension install since it is a private repo and not relevant to the issue anyways.

simplified-installer.bat

@ECHO OFF
@setlocal enableextensions
@cd /d "%~dp0"
set "scriptPath=%~dp0"
REM  --> Check for permissions
"%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system">nul 2>NUL

REM --> If error flag set, we do not have admin.
if '%errorlevel%' NEQ '0' (
    echo Requesting administrative privileges...
    goto UACPrompt
) else ( goto gotAdmin )

:UACPrompt
    if exist "%temp%\getadmin.vbs" (
        del "%temp%\getadmin.vbs"
        echo Failed to acquire elevated privilege.  Try saving this script and running it from your Desktop.
        echo;
        echo Press any key to exit.
        pause>NUL
        goto :EOF
    )
    echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\getadmin.vbs"
    echo UAC.ShellExecute "%~s0", "%*", "", "runas", 1 >> "%temp%\getadmin.vbs"

    cscript /nologo "%temp%\getadmin.vbs"
    goto :EOF

:gotAdmin
    if exist "%temp%\getadmin.vbs" ( del "%temp%\getadmin.vbs" )
:--------------------------------------
cls

powershell.exe -executionpolicy bypass -Command "& '%scriptPath%\simplified-installer.ps1'"
pause

simplified-installer.ps1

If ($env:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
    Try {
        & "$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -NonInteractive -NoProfile -File $PSCOMMANDPATH
    }
    Catch {
        Throw "Failed to start $PSCOMMANDPATH"
    }
    Exit
}


##########################Set to True for "master" or False for "develop-4"###################
$condition = $True
##############################################################################################







if ($condition) {
    $ourclonename = "pyRevit"
    $pyrevitbranch = "master"
} else {
    $ourclonename = "pyRevit-dev4"
    $pyrevitbranch = "develop-4"
}

$env:Path = "C:\Program Files\pyRevit CLI\bin"
$pyrevitinstaller = $PSScriptRoot
$pyrevitroot = "C:\pyRevit-Master"
$pyrevitclone = "$($pyrevitroot)\$($ourclonename)"






# install CLI dependencies - Assuming you already have this installed
# Write-Output "Installing .Net (4.8)..."
# Start-Process -FilePath "$($pyrevitinstaller)\ndp48-devpack-enu.exe" `
              # -ArgumentList "/q /norestart" `
              # -Wait `
              # -Verb RunAs > $null

# install/update pyRevit CLI - place in same folder as this powershell script
Write-Output "Installing pyRevitCLI 4.8.15..."
Start-Process -FilePath "$($pyrevitinstaller)\pyRevit_CLI_4.8.15.24085_admin_signed.exe" `
              -Wait `
              -ArgumentList "/VERYSILENT /NORESTART" > $null
		  
function Remove-Path ([string] $targetpath) {
    Write-Output "Confirming $($targetpath)"
    If (Test-Path $targetpath) {
        Remove-Item -Path $targetpath -Recurse -Force
    }
}

function Remove-Previous-Versions {
	Remove-Path $pyrevitclone
}

# clone pyRevit
function Clone-PyRevit() {
    # close all open Revits first
    Write-Output "Closing All Revits..."
    pyrevit revits killall
    # forget all previous pyRevit clones if any
    pyrevit clones forget $ourclonename > $null
    # clone pyRevit now
    Write-Output "Cloning pyRevit master..."
	Write-Host "Clone Name: $ourclonename"
	Write-Host "Branch: $pyrevitbranch"
    pyrevit clone $ourclonename --branch=$pyrevitbranch --dest=$pyrevitroot --debug
}
	
function Configure-PyRevit() {
    Write-Output "Configuring pyRevit..."
    pyrevit configs logs none
    pyrevit configs checkupdates enable
    pyrevit configs autoupdate enable
    pyrevit configs rocketmode enable
    pyrevit configs filelogging disable
    pyrevit configs loadbeta disable

    # this final step is critical
    # this seeds the config file for all the future users
		pyrevit configs seed --debug
}

function Attach-PyRevit() {
    Write-Output "Attaching pyRevit to Installed Revits..."
    pyrevit attach $ourclonename default --installed --debug  
}

function Test-CommandExists {
    param ($command)
    $oldPreference = $ErrorActionPreference
    $ErrorActionPreference = 'stop'
    try {
        if(Get-Command $command){
            return $true
        }
    }
    catch {
        return $false
    }
    finally {
        $ErrorActionPreference=$oldPreference
    }
}

if (Test-CommandExists "pyrevit") {
		Remove-Previous-Versions
		Clone-PyRevit --debug
		Configure-PyRevit --debug
    Attach-PyRevit --debug
}

[acco-jpitts]

Well looks like copying over the bin folder created by the non-CLI installer and adding to the clone bin folder allows pyrevit to load the ribbon successfully. Is there anyway to handle this other than zipping these dlls myself and expanding into the bin folder manually after cloning?

I see now that it is recommended to use a deployment instead of a clone of the whole branch. I have been using the cloned master branch for pyrevit, so maybe I need to reconsider this approach.

Would the deployments include these missing bin files once develop-4 is merged back to master? They are not included when using develop-4 deployments currently.

[jmcouffin]

Would the deployments include these missing bin files once develop-4 is merged back to master? They are not included when using develop-4 deployments currently.

yes, they will
but I still need to press the release button to make sure the CI works accordingly.

Well looks like copying over the bin folder created by the non-CLI installer and adding to the clone bin folder allows pyrevit to load the ribbon successfully. Is there anyway to handle this other than zipping these dlls myself and expanding into the bin folder manually after cloning?

you are right.

Sorry, I should shut up and let the grown up talking, I don't even know how to switch clones 😅 - I will try to do it and see if I can reproduce.

I plan on graduating to grown up in the coming years / decades. ;p

@sanzoghenzo we may have broken a workflow on the dev side removing the dlls ;p

[sanzoghenzo]

Would the deployments include these missing bin files once develop-4 is merged back to master? They are not included when using develop-4 deployments currently.

yes, they will but I still need to press the release button to make sure the CI works accordingly.

I don't think this will be the case anymore, since if you merge develop-4 to master, there will be no more dlls in the bin directory.

Since this is a breaking change, I suppose that we should revert back to having the dlls into the repository and only remove them on the develop branch - and we should discuss about the future of the pyrevit cli at the next online meeting!

Well looks like copying over the bin folder created by the non-CLI installer and adding to the clone bin folder allows pyrevit to load the ribbon successfully.

The files are also in the CLI folder (I don' have admin rights, so for me is %localappdata%\pyrevit cli), so the CLI could take care of copying over the bin files after the clone. Not sure if there are some missing files to source elsewhere.

[acco-jpitts]

Thank you for your attention on this guys. I ended up just forking and committing those bins myself just to get up and running for testing.

Is there previous public discussion somewhere you can point me to for the reasoning behind removing these dlls or is it easy explanation? I'm assuming it has something to do with needing to build against both net48 and net80?

[sanzoghenzo]

Is there previous public discussion somewhere you can point me to for the reasoning behind removing these dlls or is it easy explanation? I'm assuming it has something to do with needing to build against both net48 and net80?

There was a brief private discussion, but definitely not much thinking through it!
I myself was a promoter of removing binary files from the git repo, because it's not what a git repo is made for, but it didn't occur to me that clones and deployments use git content to work properly. (I only use the default, non-cli installer, so I had no direct experience with the cli)

[jmcouffin]

I will close it. Thanks for the heads-up @acco-jpitts
Everything is back to 'normal'
The CLI or pyRevit, installed from the latest wip installers should behave normally .
Switching between branches from the CLI as Well