StudioShell 1.2.0

Learn more about Target Frameworks and .NET Standard.

This package has no dependencies.

TOPIC
   about_StudioShell_Version

VERSION
   You are running version 1.2 of StudioShell.

CHANGE LOG
 Description
   The changelog documents the changes placed in each release of
StudioShell.  Each item is identified by its codeplex work item
number(s) if available.

1.2
 Resolved Issues
The user's home drive is no longer assumed to be the same drive on which
StudioShell is installed.  Previously scripts used the "home folder" ~
assuming it always referenced the user's home folder (a la the Linux
meaning of ~) which is typically c:\users\<username>.  If StudioShell is
installed on the C: drive, but the user's home drive is, say, H:, the
settings data and profile scripts would not be accessed properly, resulting
in strange behavior in the console.

The 'exit' command just hides the console; reinitializing the runspace
proved to cause unintented side-effects when the UI has been altered with
custom script commands.

Visual Studio command objects are now guaranteed to always have a name.  
Previously commands that didn't have name were unreferenceable, but would
appear in the list of items in the command path node.  This would disrupt
the console output and falsely show multiple containers under the command
node.  Nameless commands are now identified by their numeric ID value.

Formats are now defined and working for the following path nodes:
 * project templates
 * project item templates
 * tasks
 * errors
 * addins
 * fonts / color settings

10: The default console warning and error color selections are
readible (color on black background)

17: Slashes are normalized as backslashes (\) in PSDTE paths even though
forward slashes (/) are clearly superior.

In addition, the dte:/ drive name is no longer present in the
PSPath information returned by the provider.

For more information on this path issue see:
http://www.nivot.org/post/2010/03/05/PowerShellThePatchworkOfPathsPSPathsAndProviderPaths.aspx

19: Variables are now tested for existence before attempting to
create them to avoid errors; e.g., the $dte variable is already
defined in the NuGet Package Manager Console, and attempting
to redefine the variable results in an error.

A list of variables that cannot be defined is still issued
in a debug message to the console, with one exception -
if the $dte variable already exists, it is assumed to be
the root DTE variable for the Visual Studio Shell and no
message is issued.

23: Project folders now support the ability to add new items.

24: Support for read-host is now properly implemented.  Both -prompt and
-assecurestring parameters behave as they do in the standard PowerShell
console.

 Added Features    
The Cancel Executing Pipeline command actually works now.  At some
point while toying with NuGet support, I had disabled this command
functionality.  In addition, the pipeline monitoring backing the
command is now off of the main UI thread; this makes canceling pipes
that are leveraging UI-thread items (such as Visual Studio) more
responsive.

   Accessing AddIns no longer crashes VisualStudio.  The AddIns node
now closes access to the AddIn.Instance property; accessing this
property apparantly causes Visual Studio to crash.  Don't know why.

Improved support for usage from NuGet.  All of the StudioShell PSDTE
functionality is available from the NuGet Package Manager Console once
you import the StudioShell module.  Previously, menu items and commands
added via the DTE drive would be created, but would never execute if
created from the package manager console.  

See https://studioshell.codeplex.com/discussions/255426 and
https://studioshell.codeplex.com/discussions/255413

Integrated NuGet Packaging with StudioShell build.  StudioShell can now
be installed via NuGet.  Search for the package named "StudioShell" in
the public NuGet package repository.  

Support for using the PSDTE provider outside of Visual Studio.  You can now
load the PSDTE provider in a standard PowerShell console and get access
to the DTE: drive without running Visual Studio explicitly.  

Support for this scenario should be considered beta; some aspects of
the DTE: drive behave differently outside of Visual Studio.  In
addition, the visualization cmdlets available in StudioShell do not work
from the console.

Support for SQL Server Management Studio (SSMS) installations.  SSMS support
is experimental at the moment.  Moreover, several key path nodes are not
supported by SSMS and are therefore not available on the DTE drive:

* the project hive cannot be manipulated because the SSMS object model
 does not support it.

* there is no code model implemented for T-SQL, and therefore there are
 no code model hives in the DTE drive in SSMS.

* it is very likely that other portions of the DTE drive are
 non-functional or at least unstable.
 
You have been warned, use with _extreme caution_.

 DTE Drive Path Topology Changes
   
Code Model Relocation

The code model is now isolated from project items.  In previous versions, the
code model was available as a hive beneath each particular project item:

dte:/solution/projects/<project name>/<item name>/codemodel

Project item properties were available in a peer of the code model node:

dte:/solution/projects/<project name>/<item name>/itemproperties

This path topology proved inefficient for working with project items.  The
code model hive is generally massive in comparison, making recursive
operations targeting the project items cumbersome and slow.  E.g.,:

ls dte:/solution/projects -recurse -include 'packages.config'

Moving the code model addresses this issue, and provides a cleaner
and simpler path topology.  Project items remain in the same location:

dte:/solution/projects/<project name>/<item name>/itemproperties

The code model hive is now available under the following node:

dte:/solution/codemodel/<project name>/<item name>/

The code model is still organized by project and file, which is necessary
to permit modifying operations to the code model.

Selected Items Reorganization

  Previously the SelectedItems path node listed currently selected code model
elements individually; in this release the SelectedItems node is expanded with
a new CodeModel container node that houses the currently selected code model
objects.

1.1 (private release)
 Resolved Issues
   7: clear-item is now supported in the default console

8: UI thread deadlocking has been addressed in all cases except nested
consoles.

13: using shift-home and shift-end in default console selects from the
current position to start-of-input and end-of-input respectively.

14: tab completion now manages existing quotes and adds missing quotes
to paths as required

using 'exit' in the default studioshell console now releases the existing
runspace.  re-opening the console will create a new runspace initialized
to the default studioshell state.

 Added Features
   Added support for unregister-<SolutionModuleName> function in solution
modules.  This function will be invoked just before the module
is removed from the session.  The existing mechanism for catching
the unload event for the solution module proved too difficult for
the author to remember reliably:

$m = $MyInvocation.MyCommand.ScriptBlock.Module;
$m.OnRemove = {
# ...
}

This method still works of course, but you can now opt for the
simpler and more understandable:

function unregister-MySolutionModule
{
#..
}

   Project item properties are now available in the DTE hive:
   ls dte:/solution/projects/MyProject/Program.cs/itemproperties

See https://studioshell.codeplex.com/discussions/248899
1.0.1
 Resolved Issues
1: Tab completion and history walking have been hardened in the console.

2,6: Solution Folders are now recognized as containers in the console.

5: Solution Modules are now unloaded automatically if the
"AutoManageSolutionProfiles" setting is enabled.

9: The PowerShell AllUsersCurrentHost is no longer loaded.  The
"LoadPowerShellProfiles" setting now only applies
to your Current User profile script located at
~\documents\windowspowershell\profile.ps1.

11: Data panes (visualizations) now reliably appear in VS2010.

12: The default console window now consumes all available client area of
the tool window at startup.

 Added Features
10: Project item properties are now avaialble in the path heirarchy.
See dte:/solution/projects/<project>/<file>/properties.

The locals and arguments nodes under the stack frame tree now add missing
quotes to strings when you attempt to set an expression value.

The default PowerShell module path is now added to the process environment
when StudioShell is started.
 
1.0.0
 Initial Release

SEE ALSO
   https://studioshell.codeplex.com/
   http://www.studioshell.org/
   about_StudioShell_License
   PSDTE