openwrap plan and issues
50 views
Skip to first unread message
Ruben Vandeginste
Jun 28, 2012, 3:00:59 AM6/28/12
to openevery...@googlegroups.com
Sebastien,
What is the plan for openwrap-2.0.3? Which issues do you still want to
see resolved before releasing?
There are still a couple of issues that are bothering to me personally....
First is #335 which makes it a no-go for me: without proper support
for satellite and code contracts assemblies, I cannot use it. What is
your opinion on #335 and how would you solve it? I can try to
implement a solution, if you tell me how it should be solved according
to you.
Second is #334 which is not really blocking for me, but nonetheless
very annoying. I really have no clue where to look for solving this
one, but any hints on where I should look and how I could debug this?
Btw, I also noticed that the "-Debug" option does not seem to work
anymore? I thought that when I used it before, it immediately pops up
a dialog to ask me to open a Visual Studio instance to start
debugging, but it doesn't do that anymore.
Regarding #335 and #334, I really like the way OpenWrap works, in the
sense that it adds the references dynamically at build-time, and it
discovers the generated "artifacts" dynamically at build-time. This is
done by hooking into the MSBuild execution. I think that is the way it
should be done, but sadly it is not really working very well. The
problem is that most tools look at the project files in a static way,
instead of dynamically querying for the referenced assemblies through
MSBuild. For assembling all generated files, the code depends on
variables that are essentially internal to other MSBuild scripts...
and that makes it a bit vulnerable.
It is essentially possible nowadays to not use those parts of
OpenWrap, and use OpenWrap purely in an external way for dependency
management. Basically, you could not change anything in the project
files, you could make *all* dependencies "anchored" (and add them on
your project from within Visual Studio) and you could add a build task
(in the wrap descriptor) that copies specific files in the build
output path to a certain folder in the generated package. It's a bit
more work in setup and maintenance, but it is perfectly doable, and it
is gonna work as of today. (I think this is closer to how NuGet works,
from what I know about NuGet.) It also means you still get automatic
updates with "o update-wrap".
This is also basically the way how we currently build a WinForms
application. There was simply no way to get that project working when
the references were added dynamically. Next to that, for that
application we use Windows Installers (I noticed that those installer
projects actually do retrieve the referenced assemblies dynamically)
and there is not really a need to put that application in a openwrap
package.
You have talked before about supporting the static addition of
references in projects. Any idea where that is on the todo list? I do
have to say though, that to me this is not important *if* the
ReSharper plugin would work consistently and automatically. Sometimes
the plugin refuses to load, and then "sometimes" the solution is to
reboot Windows, other times it seemed that it did not like the fact
that a project was unloaded, other times we just have no clue and
nothing seems to help to get the plugin loaded. So maybe we should
just get the plugin loaded in a more stable manner.
Ruben
What is the plan for openwrap-2.0.3? Which issues do you still want to
see resolved before releasing?
There are still a couple of issues that are bothering to me personally....
First is #335 which makes it a no-go for me: without proper support
for satellite and code contracts assemblies, I cannot use it. What is
your opinion on #335 and how would you solve it? I can try to
implement a solution, if you tell me how it should be solved according
to you.
Second is #334 which is not really blocking for me, but nonetheless
very annoying. I really have no clue where to look for solving this
one, but any hints on where I should look and how I could debug this?
Btw, I also noticed that the "-Debug" option does not seem to work
anymore? I thought that when I used it before, it immediately pops up
a dialog to ask me to open a Visual Studio instance to start
debugging, but it doesn't do that anymore.
Regarding #335 and #334, I really like the way OpenWrap works, in the
sense that it adds the references dynamically at build-time, and it
discovers the generated "artifacts" dynamically at build-time. This is
done by hooking into the MSBuild execution. I think that is the way it
should be done, but sadly it is not really working very well. The
problem is that most tools look at the project files in a static way,
instead of dynamically querying for the referenced assemblies through
MSBuild. For assembling all generated files, the code depends on
variables that are essentially internal to other MSBuild scripts...
and that makes it a bit vulnerable.
It is essentially possible nowadays to not use those parts of
OpenWrap, and use OpenWrap purely in an external way for dependency
management. Basically, you could not change anything in the project
files, you could make *all* dependencies "anchored" (and add them on
your project from within Visual Studio) and you could add a build task
(in the wrap descriptor) that copies specific files in the build
output path to a certain folder in the generated package. It's a bit
more work in setup and maintenance, but it is perfectly doable, and it
is gonna work as of today. (I think this is closer to how NuGet works,
from what I know about NuGet.) It also means you still get automatic
updates with "o update-wrap".
This is also basically the way how we currently build a WinForms
application. There was simply no way to get that project working when
the references were added dynamically. Next to that, for that
application we use Windows Installers (I noticed that those installer
projects actually do retrieve the referenced assemblies dynamically)
and there is not really a need to put that application in a openwrap
package.
You have talked before about supporting the static addition of
references in projects. Any idea where that is on the todo list? I do
have to say though, that to me this is not important *if* the
ReSharper plugin would work consistently and automatically. Sometimes
the plugin refuses to load, and then "sometimes" the solution is to
reboot Windows, other times it seemed that it did not like the fact
that a project was unloaded, other times we just have no clue and
nothing seems to help to get the plugin loaded. So maybe we should
just get the plugin loaded in a more stable manner.
Ruben
Sebastien Lambla
Jun 28, 2012, 3:59:45 AM6/28/12
to <openeverything-dev@googlegroups.com>
Hey Ruben,
335 should have been fixed, as the msbuild detection has been rewritten and should have included all those files. I'm very surprised they haven't so far, but I've not had the time to look at those well. It may be differences between versions of msbuild, I'd suggest looking at that side of things first.
334, I'd recommend looking at the code that sets the plugin as enabled in the 6.1 project. You can probably liaise with Peter mounce as he did that integration work.
Debug was renamed ShellDebug as it was conflicting with the -debug on build-wrap.
Regarding the stability of the resharper integration, yes we still have some issues there and is something I will look at for 2.0.4.
As for the static mode, yes it is in the plans but it's a major undertaking. It requires building a DTE bridge for VS, a full msbuild parser that can evaluate expressions (or hosting msbuild to evaluate files, which requires two different implementations, once for v3 and v4), changing build-wrap to host msbuild to detect correctly the various outputs (and dealing with xbuild differences) or building dynamically a host msbuild when building, and that doesn't include things like automatic assemblyinfo.cs generation which is no longer possible, and requiring some UI in Vs to prevent people from mucking about with references added from OpenWrap.
We can probably do this in a phased way, and I'm putting the wrapping msbuild file in 2.0.3, but the rest is just going to take time. It's less than ideal but we will have to, as you pointed out VS is not a good enough MSBuild citizen to work well with dynamic injection.
In other words, it will probably be a 2.1 feature. The anchored with static references way is also one possible way to do this indeed, and has the same features as using nuget.exe, so it may be worth documenting it on the wiki.
Hopefully we'll get these in the pipeline very soon.
--
Seb
335 should have been fixed, as the msbuild detection has been rewritten and should have included all those files. I'm very surprised they haven't so far, but I've not had the time to look at those well. It may be differences between versions of msbuild, I'd suggest looking at that side of things first.
334, I'd recommend looking at the code that sets the plugin as enabled in the 6.1 project. You can probably liaise with Peter mounce as he did that integration work.
Debug was renamed ShellDebug as it was conflicting with the -debug on build-wrap.
Regarding the stability of the resharper integration, yes we still have some issues there and is something I will look at for 2.0.4.
As for the static mode, yes it is in the plans but it's a major undertaking. It requires building a DTE bridge for VS, a full msbuild parser that can evaluate expressions (or hosting msbuild to evaluate files, which requires two different implementations, once for v3 and v4), changing build-wrap to host msbuild to detect correctly the various outputs (and dealing with xbuild differences) or building dynamically a host msbuild when building, and that doesn't include things like automatic assemblyinfo.cs generation which is no longer possible, and requiring some UI in Vs to prevent people from mucking about with references added from OpenWrap.
We can probably do this in a phased way, and I'm putting the wrapping msbuild file in 2.0.3, but the rest is just going to take time. It's less than ideal but we will have to, as you pointed out VS is not a good enough MSBuild citizen to work well with dynamic injection.
In other words, it will probably be a 2.1 feature. The anchored with static references way is also one possible way to do this indeed, and has the same features as using nuget.exe, so it may be worth documenting it on the wiki.
Hopefully we'll get these in the pipeline very soon.
--
Seb
Ruben Vandeginste
Jun 28, 2012, 6:25:21 PM6/28/12
to openevery...@googlegroups.com
Sebastien,
> 335 should have been fixed, as the msbuild detection has been rewritten and should have included all those files. I'm very surprised they haven't so far, but I've not had the time to look at those well. It may be differences between versions of msbuild, I'd suggest looking at that side of things first.
Well, I wrote some comments on the issue itself. From what I could
see: Code Contracts reference assemblies were not picked up by the
MSBuild code. I already added a patch for that on the issue.
Next to that, satellite assemblies are picked up by the MSBuild code
and generates something along the lines of this:
[built(bin-net35,
c:\mybuildpath\myproject\scratch\bin\projectA-Debug\nl\app.resources.dll,
false)]
The problem as I see it, is that in the processing afterwards, the
fact that "app.resources.dll" must be placed inside the "nl" folder,
gets lost. That relative folder can only be correctly determined, if
you also specify the "root" of the folder.... for example something
along this:
[built(bin-net35,
c:\mybuildpath\myproject\scratch\bin\projectA-Debug\,
nl\app.resources.dll, false)]
Or in some other way.. one could use an extra parameter that contains
all possible root folders, and then during the processing in the C#
code figure out to which root a certain file belongs, and determine
the relative path based on that.
> 334, I'd recommend looking at the code that sets the plugin as enabled in the 6.1 project. You can probably liaise with Peter mounce as he did that integration work.
I think I've found it. I noticed that in the code for disposing the
plugin, there is explicit code to disable the plugin. In the start
code for ReSharper 5.1, there is explicit code to enable the plugin.
That code is not there for ReSharper 6.0 and 6.1. When I put it there,
it seems to consistently enable the plugin for me. (I noticed that
before, most of the time the plugin is not enabled, and some rare
cases the plugin was actually enabled...) I can create you a patch
tomorrow.
> Debug was renamed ShellDebug as it was conflicting with the -debug on build-wrap.
Ok.
> Regarding the stability of the resharper integration, yes we still have some issues there and is something I will look at for 2.0.4.
Ok, but I have to say that if the plugin is always enabled, that is
already going a long way.
> As for the static mode, yes it is in the plans but it's a major undertaking. It requires building a DTE bridge for VS, a full msbuild parser that can evaluate expressions (or hosting msbuild to evaluate files, which requires two different implementations, once for v3 and v4), changing build-wrap to host msbuild to detect correctly the various outputs (and dealing with xbuild differences) or building dynamically a host msbuild when building, and that doesn't include things like automatic assemblyinfo.cs generation which is no longer possible, and requiring some UI in Vs to prevent people from mucking about with references added from OpenWrap.
>
> We can probably do this in a phased way, and I'm putting the wrapping msbuild file in 2.0.3, but the rest is just going to take time. It's less than ideal but we will have to, as you pointed out VS is not a good enough MSBuild citizen to work well with dynamic injection.
>
> In other words, it will probably be a 2.1 feature. The anchored with static references way is also one possible way to do this indeed, and has the same features as using nuget.exe, so it may be worth documenting it on the wiki.
>
> Hopefully we'll get these in the pipeline very soon.
Ok, I see it's a "little bit" more work than I thought. In any case, I
would love to switch to 2.0.3 as soon as those remaining issues (334
and 335) are resolved.
Ruben
> 335 should have been fixed, as the msbuild detection has been rewritten and should have included all those files. I'm very surprised they haven't so far, but I've not had the time to look at those well. It may be differences between versions of msbuild, I'd suggest looking at that side of things first.
see: Code Contracts reference assemblies were not picked up by the
MSBuild code. I already added a patch for that on the issue.
Next to that, satellite assemblies are picked up by the MSBuild code
and generates something along the lines of this:
[built(bin-net35,
c:\mybuildpath\myproject\scratch\bin\projectA-Debug\nl\app.resources.dll,
false)]
The problem as I see it, is that in the processing afterwards, the
fact that "app.resources.dll" must be placed inside the "nl" folder,
gets lost. That relative folder can only be correctly determined, if
you also specify the "root" of the folder.... for example something
along this:
[built(bin-net35,
c:\mybuildpath\myproject\scratch\bin\projectA-Debug\,
nl\app.resources.dll, false)]
Or in some other way.. one could use an extra parameter that contains
all possible root folders, and then during the processing in the C#
code figure out to which root a certain file belongs, and determine
the relative path based on that.
> 334, I'd recommend looking at the code that sets the plugin as enabled in the 6.1 project. You can probably liaise with Peter mounce as he did that integration work.
plugin, there is explicit code to disable the plugin. In the start
code for ReSharper 5.1, there is explicit code to enable the plugin.
That code is not there for ReSharper 6.0 and 6.1. When I put it there,
it seems to consistently enable the plugin for me. (I noticed that
before, most of the time the plugin is not enabled, and some rare
cases the plugin was actually enabled...) I can create you a patch
tomorrow.
> Debug was renamed ShellDebug as it was conflicting with the -debug on build-wrap.
> Regarding the stability of the resharper integration, yes we still have some issues there and is something I will look at for 2.0.4.
already going a long way.
> As for the static mode, yes it is in the plans but it's a major undertaking. It requires building a DTE bridge for VS, a full msbuild parser that can evaluate expressions (or hosting msbuild to evaluate files, which requires two different implementations, once for v3 and v4), changing build-wrap to host msbuild to detect correctly the various outputs (and dealing with xbuild differences) or building dynamically a host msbuild when building, and that doesn't include things like automatic assemblyinfo.cs generation which is no longer possible, and requiring some UI in Vs to prevent people from mucking about with references added from OpenWrap.
>
> We can probably do this in a phased way, and I'm putting the wrapping msbuild file in 2.0.3, but the rest is just going to take time. It's less than ideal but we will have to, as you pointed out VS is not a good enough MSBuild citizen to work well with dynamic injection.
>
> In other words, it will probably be a 2.1 feature. The anchored with static references way is also one possible way to do this indeed, and has the same features as using nuget.exe, so it may be worth documenting it on the wiki.
>
> Hopefully we'll get these in the pipeline very soon.
would love to switch to 2.0.3 as soon as those remaining issues (334
and 335) are resolved.
Ruben
Sebastien Lambla
Jul 3, 2012, 11:09:55 AM7/3/12
to openevery...@googlegroups.com
you using master? All this seems to be what the behavior was in 2.0.2, and there were specific tests written around sattelite assemblies, seems something is quite wrong there.
I'll have a look tonight at that issue and take your pull request for resharper too.
Seb
________________________________________
From: openevery...@googlegroups.com [openevery...@googlegroups.com] on behalf of Ruben Vandeginste [ruben.va...@gmail.com]
Sent: 28 June 2012 23:25
To: openevery...@googlegroups.com
Subject: Re: [openeverything] openwrap plan and issues
Ruben Vandeginste
Jul 3, 2012, 6:34:17 PM7/3/12
to openevery...@googlegroups.com
hey Sebastien,
yup, that was using master... I will take a look at those tests tomorrow night.
Ruben
yup, that was using master... I will take a look at those tests tomorrow night.
Ruben
Ruben Vandeginste
Jul 9, 2012, 4:50:10 PM7/9/12
to openevery...@googlegroups.com
Sebastien,
I checked the tests... they are fine, but they test the correct
processing of the generated "built" commands, and I think the problem
is closer to the MSBuild code. I debugged the code, and I noticed in
the "PublishPackageContent" class that you use the metadata
"TargetPath" to determine where the generated assembly belongs inside
the binary package. However, in my test, the "TargetPath" for all
assemblies (thus including the satellite and code contracts
assemblies) is equal to ".", so all assemblies end up in the root
"bin-net35". Is that the problem?
Ruben
I checked the tests... they are fine, but they test the correct
processing of the generated "built" commands, and I think the problem
is closer to the MSBuild code. I debugged the code, and I noticed in
the "PublishPackageContent" class that you use the metadata
"TargetPath" to determine where the generated assembly belongs inside
the binary package. However, in my test, the "TargetPath" for all
assemblies (thus including the satellite and code contracts
assemblies) is equal to ".", so all assemblies end up in the root
"bin-net35". Is that the problem?
Ruben
Reply all
Reply to author
Forward
0 new messages