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

Already on GitHub? Sign in to your account

Investigate using MSI vs VSIX for deployment. #46

Closed
dmiller opened this Issue Jan 20, 2012 · 18 comments

Comments

Projects
None yet
3 participants

dmiller commented Jan 20, 2012

No description provided.

@jmis jmis was assigned Jan 20, 2012

Contributor

jmis commented Jan 22, 2012

I've had some time to think about my concerns with the current VSIX deployment strategy. I recommend that we deploy ClojureCLR separately from vsClojure via an MSI from the Visual Studio Gallery. vsClojure does not require any setup beyond copying files so it will continue to be deployed via a VSIX.

I'd like to emulate the same relationship that .NET has to Visual Studio. That is, the ClojureCLR runtime ships separately from vsClojure. However, if you choose to install vsClojure without the runtime then the runtime will install for you. This should be possible via the Visual Studio Gallery dependency feature. Currently, the complexity within the vsClojure deployment is around setting up the ClojureCLR runtime so that it can be used by both the extension and MSBuild. However, users wanting to access the runtime outside of these two applications will have a difficult time finding the installation. Moreover, any tools will not be able to locate the runtime in these user-specific installation directories for Visual Studio extensions. Deploying ClojureCLR via an MSI will allow registry values to be set, assemblies added to the GAC, etc. providing a universal way for tools and users to access the runtime.

dmiller commented Jan 22, 2012

To date, I've avoided putting ClojureCLR in the GAC. I won't say that my
reasons have been coherent or correct. The reasons include:

(1) having to deal with assembly signing in an open-source development
scenario
(2) The need to sign assemblies coming out of the AOT-compilation process.
And there are a lot of them.

I had thought about creating a NuGet distribution for ClojureCLR. Not sure
if there is any way to integrate that. It wouldn't need to be part of the
vsClojure install. Rather, when a Clojure project is created, the version
of ClojureCLR is specified, and downloaded via NuGet to support the
project. That can be scripted as part of the project creation process.

On Sat, Jan 21, 2012 at 6:25 PM, jmis <
reply@reply.github.com

wrote:

I've had some time to think about my concerns with the current VSIX
deployment strategy. I recommend that we deploy ClojureCLR separately from
vsClojure via an MSI from the Visual Studio Gallery. vsClojure does not
require any setup beyond copying files so it will continue to be deployed
via a VSIX.

I'd like to emulate the same relationship that .NET has to Visual Studio.
That is, the ClojureCLR runtime ships separately from vsClojure. However,
if you choose to install vsClojure without the runtime then the runtime
will install for you. This should be possible via the Visual Studio
Gallery dependency feature. Currently, the complexity within the vsClojure
deployment is around setting up the ClojureCLR runtime so that it can be
used by both the extension and MSBuild. However, users wanting to access
the runtime outside of these two applications will have a difficult time
finding the installation. Moreover, any tools will not be able to locate
the runtime in these user-specific installation directories for Visual
Studio extensions. Deploying ClojureCLR via an MSI will allow registry
values to be set, assemblies added to the GAC, etc. providing a universal
way for tools and users to access the runtime.


Reply to this email directly or view it on GitHub:
#46 (comment)

Contributor

jmis commented Jan 22, 2012

I think I've seen other IDEs download the runtime when you create a project. I'll look into how difficult it would be to have NuGet download ClojureCLR when it's needed.

Contributor

jmis commented Jan 22, 2012

NuGet whitelists supported project types so it won't work with vsClojure. We also won't be able to use the NuGet template wizard because it only supports loading packages that are bundled with the template. However, we may still be able to script the installation of a package at project load. I'll have to continue looking into it.

Would it be possible to create a more robust build process for ClojureCLR that would sign the assemblies?

dmiller commented Jan 22, 2012

I'm sure it can be done. I'll look into it.

I'll also have to modify the loadi mechanism.

This is very unfortunate. I had planned to use nuget to deal with adding
contribs to clojure projects.

Is there any justification for this whitelist?

On Sun, Jan 22, 2012 at 12:30 AM, jmis <
reply@reply.github.com

wrote:

NuGet whitelists supported project types so it won't work with vsClojure.
We also won't be able to use the NuGet template wizard because it only
supports loading packages that are bundled with the template. However, we
may still be able to script the installation of a package at project load.
I'll have to continue looking into it.

Would it be possible to create a more robust build process for ClojureCLR
that would sign the assemblies?


Reply to this email directly or view it on GitHub:
#46 (comment)

dmiller commented Jan 22, 2012

This doesn't help:
http://docs.nuget.org/docs/reference/packages-in-visual-studio-templates ?

(Early morning rush, only did a quick scan.)

Maybe we could create a dummy csharp project to contain the goodies?

On Sun, Jan 22, 2012 at 6:24 AM, David Miller dmiller2718@gmail.com wrote:

I'm sure it can be done. I'll look into it.

I'll also have to modify the loadi mechanism.

This is very unfortunate. I had planned to use nuget to deal with adding
contribs to clojure projects.

Is there any justification for this whitelist?

On Sun, Jan 22, 2012 at 12:30 AM, jmis <
reply@reply.github.com

wrote:

NuGet whitelists supported project types so it won't work with vsClojure.
We also won't be able to use the NuGet template wizard because it only
supports loading packages that are bundled with the template. However, we
may still be able to script the installation of a package at project load.
I'll have to continue looking into it.

Would it be possible to create a more robust build process for ClojureCLR
that would sign the assemblies?


Reply to this email directly or view it on GitHub:
#46 (comment)

Contributor

jmis commented Jan 22, 2012

Your link refers to the template wizard that I mentioned earlier. It requires that the NuGet package be bundled with either the extension or the template.

I couldn't find much documentation on supported project types so I had to dig into their code. When it loads the package manager it validates the project type against a supported list of project types. I've appended the code fragments below.

NuGetPackage.cs:

if (project != null && !project.IsUnloaded() && project.IsSupported())
{
ShowManageLibraryPackageDialog(project);
}

ProjectExtensions.cs:

public static bool IsSupported(this Project project)
{
return project.Kind != null && _supportedProjectTypes.Contains(project.Kind);
}

private static readonly HashSet _supportedProjectTypes
= new HashSet(StringComparer.OrdinalIgnoreCase) {
VsConstants.WebSiteProjectTypeGuid,
VsConstants.CsharpProjectTypeGuid,
VsConstants.VbProjectTypeGuid,
VsConstants.JsProjectTypeGuid,
VsConstants.FsharpProjectTypeGuid,
VsConstants.NemerleProjectTypeGuid,
VsConstants.WixProjectTypeGuid };

dmiller commented Jan 22, 2012

How long did it take to find taht?

That really sucks.

We could fork and post our own. :)

On Sun, Jan 22, 2012 at 1:05 PM, jmis <
reply@reply.github.com

wrote:

Your link refers to the template wizard that I mentioned earlier. It
requires that the NuGet package be bundled with either the extension or the
template.

I couldn't find much documentation on supported project types so I had to
dig into their code. When it loads the package manager it validates the
project type against a supported list of project types. I've appended the
code fragments below.

NuGetPackage.cs:

if (project != null && !project.IsUnloaded() && project.IsSupported())
{
ShowManageLibraryPackageDialog(project);
}

ProjectExtensions.cs:

public static bool IsSupported(this Project project)
{
return project.Kind != null &&
_supportedProjectTypes.Contains(project.Kind);
}

private static readonly HashSet _supportedProjectTypes
= new HashSet(StringComparer.OrdinalIgnoreCase) {
VsConstants.WebSiteProjectTypeGuid,
VsConstants.CsharpProjectTypeGuid,
VsConstants.VbProjectTypeGuid,
VsConstants.JsProjectTypeGuid,
VsConstants.FsharpProjectTypeGuid,
VsConstants.NemerleProjectTypeGuid,
VsConstants.WixProjectTypeGuid };


Reply to this email directly or view it on GitHub:
#46 (comment)

dmiller commented Jan 22, 2012

Even C++ is not supported. I found some discussions on that on the nuget
codeplex site.

Also: http://nuget.codeplex.com/workitem/1835
http://nuget.codeplex.com/workitem/1810
http://nuget.codeplex.com/workitem/1740 (Cobol!)

On Sun, Jan 22, 2012 at 1:10 PM, David Miller dmiller2718@gmail.com wrote:

How long did it take to find taht?

That really sucks.

We could fork and post our own. :)

On Sun, Jan 22, 2012 at 1:05 PM, jmis <
reply@reply.github.com

wrote:

Your link refers to the template wizard that I mentioned earlier. It
requires that the NuGet package be bundled with either the extension or the
template.

I couldn't find much documentation on supported project types so I had to
dig into their code. When it loads the package manager it validates the
project type against a supported list of project types. I've appended the
code fragments below.

NuGetPackage.cs:

if (project != null && !project.IsUnloaded() && project.IsSupported())
{
ShowManageLibraryPackageDialog(project);
}

ProjectExtensions.cs:

public static bool IsSupported(this Project project)
{
return project.Kind != null &&
_supportedProjectTypes.Contains(project.Kind);
}

private static readonly HashSet _supportedProjectTypes
= new HashSet(StringComparer.OrdinalIgnoreCase) {
VsConstants.WebSiteProjectTypeGuid,
VsConstants.CsharpProjectTypeGuid,
VsConstants.VbProjectTypeGuid,
VsConstants.JsProjectTypeGuid,
VsConstants.FsharpProjectTypeGuid,
VsConstants.NemerleProjectTypeGuid,
VsConstants.WixProjectTypeGuid };


Reply to this email directly or view it on GitHub:
#46 (comment)

Contributor

jmis commented Jan 22, 2012

It didn't take too long to find that code. So far, we've learned that separating the runtime from the extension isn't going to be trivial. What do you think about shipping a recompiled 1.2 and 1.3 via the current distribution method for this release? We'll need to continue to investigate our NuGet and MSI options for a later release.

dmiller commented Jan 22, 2012

Simplest path for now.

On Sun, Jan 22, 2012 at 2:35 PM, jmis <
reply@reply.github.com

wrote:

It didn't take too long to find that code. So far, we've learned that
separating the runtime from the extension isn't going to be trivial. What
do you think about shipping a recompiled 1.2 and 1.3 via the current
distribution method for this release? We'll need to continue to
investigate our NuGet and MSI options for a later release.


Reply to this email directly or view it on GitHub:
#46 (comment)

@jmis jmis closed this Jan 26, 2012

Doesn't VsClojure need to add registry entries in order for Visual Studio to know to open a Clojure project with VsClojure? Right now, I'm unable to open a Clojure project from the shell for this reason. This would point toward an MSI installation rather than VSIX.

Contributor

jmis commented Jan 26, 2012

vsClojure doesn't deal directly with registry values. However, I believe that Visual Studio reads attributes on types within vsClojure to generate registry entries. What error message are you seeing when you try to open a Clojure project?

I've attached an image of the error message.

On Thu, Jan 26, 2012 at 2:36 PM, jmis
reply@reply.github.com
wrote:

vsClojure doesn't deal directly with registry values. However, I believe that Visual Studio reads attributes on types within vsClojure to generate registry entries. What error message are you seeing when you try to open a Clojure project?


Reply to this email directly or view it on GitHub:
#46 (comment)

By the way, Visual Studio will open a Clojure project if it is already
open; it's just when you try to open a Clojure project or a solution
containing one from the shell that it borks.

On Thu, Jan 26, 2012 at 2:36 PM, jmis
reply@reply.github.com
wrote:

vsClojure doesn't deal directly with registry values.  However, I believe that Visual Studio reads attributes on types within vsClojure to generate registry entries.  What error message are you seeing when you try to open a Clojure project?


Reply to this email directly or view it on GitHub:
#46 (comment)

Contributor

jmis commented Jan 26, 2012

Ah, I see what you mean now. It may be possible to have vsClojure add the registry value during its initial setup.

dmiller commented Jan 26, 2012

Create new issue on that?

On Thu, Jan 26, 2012 at 1:58 PM, jmis <
reply@reply.github.com

wrote:

Ah, I see what you mean now. It may be possible to have vsClojure add the
registry value during its initial setup.


Reply to this email directly or view it on GitHub:
#46 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment