#Property in PowerShell not showing but VS Code works fine

112 messages · Page 1 of 1 (latest)

proven mesa
#

Ive seen this before i think your missing some lib being loaded.
Guessing the ms security one, forget the name.

Can compare which assemblies are loaded in the sessions to see

proven mesa
#

I think you can skip $pshome and .dll it should know about that assembly.
Something in the ps extension probably loads it. Havnt looked at it too closely

compact inlet
#

if you're using -Path it will need the absolute path. If you use -AssemblyName and remove the .dll from the end it should work

#

there is a bug with -ReferencedAssemblies

#

you could do -ReferencedAssemblies (Convert-Path ("$([psobject].Assembly.Location)\..\*.dll")) tbh 😛

#

to overcome that bug*

west wolf
#

it's a module fyi, Import-Module Microsoft.PowerShell.Security

compact inlet
#

mmm you're right

#

not gonna work for this one

west wolf
#

but yeah it's a script property that tries to construct a Microsoft.Powershell.Commands.EnhancedKeyUsageProperty object. That type is in MP.Security

compact inlet
#

i'd compile all these files in the build process and publish them in the nuget package instead of Add-type tbh

west wolf
#

indirect answer: managing references for a bunch of different assemblies that also possibly target different frameworks is very challenging, and generally not super feasible for Add-Type to manage. Really best to use the dotnet sdk

direct question to get to direct answer: what's the error you're getting?

#

so when a type references an assembly, the load is done lazily when it's needed. So if not part of that type actually references a type or member from that assembly, it doesn't really do anything

#

yeah it's really handy! and also sometimes annoying

#

it's also useful for shipping code that references platform specific resources, but that code path is guarded with a platform check

#

so you can generally avoid shipping several versions of the same assembly for each platform

#

a few other even more niche benefits, but yeah the big one is load times for sure

#

yep! or even process architecture

#

no it should, afaik anyway. I meant the lazy loading is useful if you have platform specific code

#

generally stuff calling OS or otherwise unmanaged apis

#

p/invoke basically

#

better significantly editor experience, source generators, better handling of nuget packages, and as complexity increases eventually Add-Type will stop being feasible all together

#

load times also, especially in places with heavy real time scanning. iirc roslyn ends up making a temp file to compile with and that usually chugs for an extra second or two

#

well Add-Type with a path to a dll is very different, it doesn't compile at all

#

arguably should have been a different command all together because that's pretty confusing, but it is what it is

#

fwiw this is a conversation that has taken place a lot of times over the years. Most folks (including myself) start out thinking all they need is Add-Type -TypeDef. And often it's technically true, but the experience is much worse due to lack of debugging/intellisense/other editor goodies. And at a certain level of complexity some of the systems start to have a hard time keeping up

#

I don't know, it's possible. Usually the problem is around assembly references

#

yeah I suppose you could go through the work of maintaining a valid project and then just not compile. Kinda seems like a waste

#

hmmm can you elaborate on what you mean?

#

you're still compiling with roslyn though, just choosing to do it at runtime with a worse version of the tool stack. Trust me, I love PowerShell too, but that's not really relevant 😛

#

yeah, the hard part for folks is usually the project set up

#

almost no one afaik sets up a full project and then doesn't do the easy part

proven mesa
#

you dont really need a project if your doing it in vscode though? just create a .cs file and start whacking away 🤣
personally i went and compiled when i needed to use third party libs and their types in my code, thats just painful with add-type..

west wolf
#

PowerShell's Add-Type uses the same underlying api, but doesn't have all the other infrastructure the sdk has around it

west wolf
#

unless they've changed it very recently, those do need a project to work

proven mesa
west wolf
proven mesa
#

why wouldnt intellisense and debugging work without a project notlikethiscat

west wolf
#

the few times I have to play in UI I do use VS but otherwise much prefer not to use it

west wolf
proven mesa
#

it could just ask or make an assumption on latest or have a dropdown somewhere

#

or like a global config setting default framework = x

west wolf
#

sure, for the small handful of probably exclusively powershell folks doing that 😛

proven mesa
#

yes, see you understand

#

😄

west wolf
#

generally a C# dev doesn't have a way to just run a cs file

#

yeah, the solution is super easy

#

but the other issue, often folks using PowerShell are referencing assemblies they wouldn't otherwise know how to specify

#

so chances are high there would be something that doesn't work. And at that point you might as well just learn the stack

proven mesa
#

im still learning c# but i much prefer powershell.. i think C# is a bit too strict and verbose.. and because i dont know it well i always feel like i write super inefficient code

west wolf
#

I do want to touch on this a little bit more because I definitely see folks share this sentiment sometimes, and even once felt it myself.

I remember very specifically feeling like using a different language or tool was an admission that PowerShell wasn't good enough. Like I wanted to prove you can do x or y in PowerShell

As someone who has truly built their life around PowerShell, I can tell you it's non-sensical. You can still build tools for PowerShell in other languages. PowerShell has a specific focus, it is intentionally not trying to be the best tool in certain categories

compact inlet
proven mesa
west wolf
#

I meant like C#, but someone did actually make a cargo package that hosts the CLR and runs PowerShell lol

proven mesa
#

yea i've used visual studio with a proper project and everything when doing c# before, i still didn't like it that much :p
it's not that i think powershell is the best language for everything.

i still do and try and write a bit of c# when i find something fun to try.

it probably just boils down to what im most comfortable with.

west wolf
#

dunno if it was actually publishable but yeah there's ways

#

hell I once used a now defunct node package that hosted the CLR to run PowerShell code from typescript in electron

#

but managed languages like C#/F# are significantly more clear ways to provide actual value to a PowerShell session

compact inlet
west wolf
#

it's a huge PITA

#

or at least was when I tried as well

west wolf
#

and santi I think?

#

definitely took a long time to finally learn C# can't remember if they immediately jumped on the SDK when they did

west wolf
#

oooo that's neat I didn't know they were build on C#

compact inlet
#

And I was wrong

west wolf
#

I wrote an enter the gungeon mod at one point which is a mono game as well

#

(though, locked to a super old framework version as it's an old game)

compact inlet
#

You did your part to change my mind hehe

#

Thank god you did

west wolf
#

oh did it not originally have achievements on steam? interesting!

#

there's no supported way to do that no. Outside of some rare use cases (like the provider commands for instance) I don't recommend using dynamic parameters

#

so when I say that most of the time what I mean is "technically you can use modding tools to do w/e you want but it'll be incredibly flimsy"

#

what I should say is "nah there's no way to do that" but I don't like half truths if I can help it

#

when I say modding tools I'm referring to stuff like MonoMod/Harmony. You can use those to patch code at runtime

#

yeah technically that too, would be a lot harder than monomod though

#

yeah I mean though these repos are written in C# for use in PowerShell, most of them don't technically need to be C#

though some parts would be way more annoying in PowerShell for sure

#

are you familiar with what CIL is?

#

formally MSIL

#

formerly*

#

it's the intermediate instruction language that most dotnet languages are compiled to, though on disk each instruction type is stored as a byte and it's arguments are a reference to a table in metadata

#

that instruction "language" is just in time compiled into machine code once it's loaded at runtime

#

the ILAssembler module lets you write in this language (or rather a custom dialect of it) and it's more or less directly translated to that exact instruction in a delegate you can invoke. Mostly for prototyping/testing

#

only supports methods atm

#

(the parts that start with .method. Also excluding attributes and generic params)

#

yep!

#

yep just a constructor

#

actor?

#

like threat actor? or does that have some broadway meaning I don't know? 😁

#

ah gotcha. Yeah .ctor is the name given to instance constructors in metadata. .cctor for static

west wolf
#

some folks set up a runspace that stays open and looks for stale runspaces. Personally I think a dedicated background task runspace that you reuse is the way to go

#

but also fwiw, the infrastructure around the thread pool in c# is basically what you're asking for

#

they don't stop optimization, but I'd jsut go with a sync hash or similar

#

so for functions I would go with a module, and import it into the reused runspace via initialsessionstate

#

probably keeping the runspace open on a loop that reads from a blocking collection. Use the blocking collection to send work to the background runspace

#

you can do [initialsessionstate]::CreateDefault2() to get a pretty close to normal session. It is slower to load than not doing that, but reuse is key

#

thread jobs are wrappers around runspaces, so it all depends on how you do it but yeah in most cases it will be faster

#

well I also I don't really recommend using PowerShell classes across modules, or in public facing metadata like parameter types or attribute arguments

#

the only somewhat consistent way to do is is unsupported and imo bad for the ecosystem. Unless folks arbitrarily add their own namespaces I think a large influx of folks using type accelerators would step on each other very quickly

#

I was very against that method being documented and tbh I was under the impression because of the conversation I had with them that they were no longer going to document it

#

but apparently I should have followed up

#

type accelerators aren't really a well tested bit of functionality for customization. And are subject to change. I don't recommend that method at all

gotta run for a bit gonna watch tv with the wife, feel free to ask more questions though I'll get 'em later