Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Relative paths not correctly resolved by 'using module' statement #99

Closed
daviwil opened this issue Jan 2, 2016 · 3 comments
Closed

Relative paths not correctly resolved by 'using module' statement #99

daviwil opened this issue Jan 2, 2016 · 3 comments
Labels
Issue-Bug A bug to squash.
Milestone
0.5.0

Comments

@daviwil
Copy link
Contributor

daviwil commented Jan 2, 2016

@AndrewGaspar identified this issue and filed a bug at the PowerShell/vscode-powershell repo:

PowerShell/vscode-powershell#64

We need to provide the proper working directory to the PowerShell parser when parsing each file so that module path resolution works correctly.
@daviwil daviwil added the Issue-Bug A bug to squash. label Jan 2, 2016
@daviwil daviwil added this to the 0.4.0 milestone Jan 2, 2016
@daviwil daviwil mentioned this issue Jan 2, 2016
Closed
daviwil added a commit that referenced this issue Jan 10, 2016
@daviwil
Fix #99: 'using module' relative path resolution
76626af 
This change fixes an issue with relative module path resolution with the
'using module' statement in more recent versions of PowerShell v5.  A new
method overload was added to the PowerShell API's Parser.ParseInput method
which allows the script's path to be specified.  By using this parameter,
the PowerShell parser resolves relative module paths correctly.

This change also required a change to how PowerShell API usage is verified
for different PowerShell versions.  Since the PowerShell v5 reference
assemblies don't (yet) contain Parser.ParseInput overload, we now have to
make a distinction between the PowerShell v5 which is specified by the
reference assemblies and the one that is currently shipped in the latest
official Windows 10 release (10586).  Once updated reference assemblies
have been shipped for PowerShell v5 we may revisit this approach.
@daviwil
Copy link
Contributor Author

daviwil commented Jan 10, 2016

I've got a fix for this but the build fails on AppVeyor because it isn't using the latest Windows/WMF release. I'll see if I can get someone to update the imagine this week so I can include this fix with the 0.4.0 release. Here's the branch where the fix is stored:

https://github.com/PowerShell/PowerShellEditorServices/tree/daviwil/using-module-fix

@daviwil
Copy link
Contributor Author

daviwil commented Feb 5, 2016

I'm going to push this one out for 0.4.1 to give a little more time for getting the AppVeyor situation straightened out.

@daviwil daviwil modified the milestones: 0.4.1, 0.4.0, 0.4.2 Feb 5, 2016
@daviwil
Copy link
Contributor Author

daviwil commented Feb 16, 2016

Moving this ahead to 0.5.0 because WMF 5 RTM won't be out in time to have it installed on our AppVeyor image for 0.4.2 (VS Code 0.4.1)

@daviwil daviwil modified the milestones: 0.5.0, 0.4.2 Feb 16, 2016
@daviwil daviwil closed this as completed in 20e749b Mar 8, 2016
daviwil added a commit that referenced this issue Mar 8, 2016
@daviwil
Merge pull request #183 from PowerShell/daviwil/using-module-fix
a1e6dbc 
Fix #99: 'using module' relative path resolution
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Issue-Bug A bug to squash.
Projects
None yet
Milestone
0.5.0
Development

No branches or pull requests
1 participant
@daviwil