testing openwrap (f/semver) and openwrap-shell (master)

[Ruben Vandeginste]

Sebastien,

I built openwrap-shell from master (commit
a2cac77af2c1c538903a7c26a1c6a0b1127af840) and this version of the
shell seems to work. I did have to install the exe manually in
AppData/Local: I replaced the existing o.exe with the o.exe built from
master. I tried removing the openwrap folder from AppData/Local and
install by running the exe, but this failed. (Further testing shows
that the shell still acts weird from time to time and tries to
download openwrap-1.0.2 and then complains that it cannot start...)

I built openwrap from the "f\semver" branch. I hit a bug in
build-wrap: stack trace and patch below. I also added a patch for
support for the most recent ReSharper plugin: it is simply registering
the correct version, and can use the existing 6.1.0 code.

I will test more later on. I tested with versions in the form
"x.y.z.*" and I noticed that "update-wrap" seems to prefer versions
that are as low as possible. Is that as intended?

Ruben
----

Stacktrace from the bug:
Project "C:\Development\Test\PPWCode.Util.OddsAndEnds\src\I\PPWCode.Util.OddsAndEnds.I.csproj"
on node 1 (Clean target(s)).

The "InitializeOpenWrap" task failed unexpectedly.
[C:\Development\Test\PPWCode.Util.OddsAndEnds\src\I\PPWCode.Util.OddsAndEnds.I.csproj]
System.Reflection.TargetInvocationException: Exception has been
thrown by the target of an invocation. --->
System.ArgumentNullException: Value cannot be null.
Parameter name: path
at System.IO.DirectoryInfo..ctor(String path)
at OpenFileSystem.IO.FileSystems.Local.Win32.Win32FileSystem.GetDirectory(String
directoryPath) in
c:\src\openfilesystem\src\OpenFileSystem\FileSystems\Local\Win32\Win32FileSystem.cs:line
10
at OpenWrap.Build.BuildInitializer.Initialize(String projectFile,
String currentDirectory) in
c:\Development\OpenWrap\new\openwrap\src\OpenWrap\Build\BuildInitializer.cs:line
17
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, SignatureStruct& sig,
MethodAttributes methodAttributes, RuntimeType typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, Signature sig,
MethodAttributes methodAttributes, RuntimeType typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj,
BindingFlags invokeAttr, Binder binder, Object[] parameters,
CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj,
BindingFlags invokeAttr, Binder binder, Object[] parameters,
CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at OpenWrap.Build.InitializeOpenWrap.Execute() in
c:\Development\OpenWrap\new\openwrap\src\OpenWrap.Build.Bootstrap\InitializeOpenWrap.cs:line
41
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost
taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost
taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask,
Boolean& taskResult)

I checked the code, and in OpenWrap.CSharp.targets (line 46), the
InitializeOpenWrap task is initialized with 2 parameters: StartDebug
and CurrentProjectFile. The InitializeOpenWrap task also has a
property CurrentDirectory, which does not seem to be set. This means
that the Initialize method in the BuildInitializer class is called
with currentDirectory = null.


Patch for OpenWrap.CSharp.targets:
diff --git a/src/OpenWrap.Build.Tasks/OpenWrap.CSharp.targets
b/src/OpenWrap.Build.Tasks/OpenWrap.CSharp.targets
index 01d4e9e..c86b6d1 100644
--- a/src/OpenWrap.Build.Tasks/OpenWrap.CSharp.targets
+++ b/src/OpenWrap.Build.Tasks/OpenWrap.CSharp.targets
@@ -43,7 +43,7 @@
</PropertyGroup>

<Target Name="OpenWrap-Initialize">
- <InitializeOpenWrap StartDebug="$(OpenWrap-StartDebug)"
CurrentProjectFile="$(MSBuildProjectFullPath)" >
+ <InitializeOpenWrap StartDebug="$(OpenWrap-StartDebug)"
CurrentProjectFile="$(MSBuildProjectFullPath)"
CurrentDirectory="$(MSBuildProjectDirectory)" >
<Output TaskParameter="Name" PropertyName="OpenWrap-PackageName" />
<Output TaskParameter="Scope" PropertyName="_OpenWrap-Scope"
Condition="'$(OpenWrap-Scope)' == ''" />
<Output TaskParameter="DescriptorPath"
PropertyName="_OpenWrap-DescriptorPath"
Condition="'$(OpenWrap-DescriptorPath)' == ''" />


Patch for adding support for the new version 6.1.1 of the ReSharper plugin:
diff --git a/src/OpenWrap.VisualStudio.SolutionPlugins/ReSharper/ResharperLoaderPlugin.cs
b/src/OpenWrap.VisualStudio.SolutionPlugins/ReSharper/ResharperLoader
index 6ffdcd9..bc6cc24 100644
--- a/src/OpenWrap.VisualStudio.SolutionPlugins/ReSharper/ResharperLoaderPlugin.cs
+++ b/src/OpenWrap.VisualStudio.SolutionPlugins/ReSharper/ResharperLoaderPlugin.cs
@@ -20,7 +20,8 @@ namespace OpenWrap.SolutionPlugins.VisualStudio.ReSharper
{ new Version("5.0.1659.36"),
"OpenWrap.Resharper.PluginManager, OpenWrap.Resharper.500" },
{ new Version("5.1.1727.12"),
"OpenWrap.Resharper.PluginManager, OpenWrap.Resharper.510" },
{ new Version("6.0.2162.902"),
"OpenWrap.Resharper.PluginManager, OpenWrap.Resharper.600" },
- { new Version("6.1.37.86"),
"OpenWrap.Resharper.PluginManager, OpenWrap.Resharper.610" }
+ { new Version("6.1.37.86"),
"OpenWrap.Resharper.PluginManager, OpenWrap.Resharper.610" },
+ { new Version("6.1.1000.82"),
"OpenWrap.Resharper.PluginManager, OpenWrap.Resharper.610" }
};

readonly IFileSystem _fileSystem;

[Sebastien Lambla]

Hey Ruben,

First, thanks a million for the testing, it's highly appreciated.

There's a few hurdles on the branch atm as I've been changing stuff around to support mono compilation.

The upgrade path is a bit of an issue between 1.0 and 2.0, but I've decided to leave that work until the rest has been completed.

The stack trace you got is already fixed, the code should land this evening.

The shell having strange behaviour, yes I did notice that and I'm trying to track down whats going on, I've got an outstanding issue around -systemrepositorypath so am gonna have a look at that at that point.

The update not using the latest build number is indeed a bit strange, I'm going to have a look at that, there's something saucy going on with build numbers in semver 2 (non-withstanding the spec being confusing...). I've opened a ticket at https://github.com/openrasta/openwrap/issues/317

Seb

+++ rPlugin.cs