stuartadams

Are you using the Cache: scope or the Server-Level cache?

I’m calling Get-PSUCache in a few different functions in a module that both a dashboard and an API endpoint use.

docs.powershelluniversal.com

Product: PowerShell Universal
Version: 5.6.13

I noticed that 5.6.7 included the addition of support for using wildcards with the Get-PSUCache cmdlet, but I can’t seem to get it to work.

The issue where it was added is here and seems to imply that I would just need to use an asterisk character in the value of the -Key parameter, but I’m not having any success. The API docs for Get-PSUCache seems to imply that ‘Accept wildcard characters’ is false? Has anyone implemented this?

Improve Efficiency of Cache Cmdlets · Issue #5095 · ironmansoftware/powershell-universal

We’ve noticed in 5.5 some problems with editing portal pages. Sometimes they will edit, allow us to select a Script Table, and Save, but most of the time their contents disappear after editing.

I can manually edit portalPages.psd1 and add Components to a page, but as soon as I look at the page, the contents of the Component I just added are removed from portalPages.psd1.

Has anyone else noticed this and found a resolution?

Product: PowerShell Universal
Version: 5.5.3

Yep, that’s exactly right

I have a note in my dev environment documentation that addresses this, I’m pretty sure the solution came from this forum at some point but I can’t find the original post now - This is the solution that I’ve had to use a few times in the past:

There can sometimes be an error indicating ‘There is no tracking information for the current branch.’ - The solution is to modify the .git\config file in the repository folder, adding the following, making sure to substitute ‘mybranch’ with the branch configured in the Git sync settings.

[branch "mybranch"]
    remote = origin
    merge = refs/heads/mybranch

If there is, I couldn’t find it either. We started looking at switching because our LiteDB file size had grown so large, but eventually decided it was worth a clean install of our production environment. Our database size went from nearly 6GB to around 50MB. I think if we had been able to migrate we probably wouldn’t have had the same success.

Is your app running in the integrated environment?

Per the docs on Environments (linked below), “The integrated environment does not support running as alternate credentials.” - You’ll need to create an additional environment and configure this app to use it.

Environments | PowerShell Universal

Looks like this will be in v5

github.com/ironmansoftware/issues

Were you ever able to accomplish this? There’s another post on the forum with a similar issue, and my experience seems to be the same as yours.

It may be due to my lack of familiarity with the DynamicParam block, I’ll have to do some testing outside of PowerShell Universal to be sure.

For anyone who finds this post and wonders about a solution, we ended up solving this by uninstalling, cleaning up any remnants of the existing install and reinstalling when we updated to 4.2.21, which is new enough to use SQLite by default rather than LiteDB.

We had used LiteDB Studio to try to figure out where the problem was, but the more we found, the less worthwhile it seemed to troubleshoot seeing as the migration to SQLite was the ultimate goal anyway.

Just wondering if I’m the only one that’s ever observed something like this:

Our Database.db (LiteDB5) size has somehow managed to grow to over 5GB. I had suspected it was growing due to a lot of retained jobs and logging targets set to retain 365 days, but both of those have been corrected. File size has been static at around 5.77 GB (6,196,813,824 bytes) for a couple days now. Anything obvious I should be looking for?

Product: PowerShell Universal
Version: 4.2.9

I’ll throw another wrench into this for you - We try to put as much as possible in modules, as we have some functions that see reuse between API endpoints and scripts

One advantage of this is that both our scripts and our endpoints files are smaller now