Target project prerequisite

Sep 22, 2010 at 3:31 AM

I ran into something today that was unexpected.  I installed the Ninject.MVC3 project into a MVC2 project.  The auto wirecode did not work since it was written to work with APIs in MVC3.  This made me think that some packages should have prequisites that need to be fulfilled by a project and a very friendly error message when the prereqs are not fulfilled.

Repro:

  1. Create a New MVC2 application
  2. open the package management console
  3. add-package ninject.mvc3
  4. build project

Result: The project will not build, because the package was meant for a project using the MVC 3 version of the framework

Expected: The package management console should warn that this package can only be applied to a MVC3 application.

Thoughts?

Developer
Sep 22, 2010 at 3:36 AM

This is definitely on our list of things to solve. It's also something that needs to be expressed in the manifest. One problem we have with implementing this is how to detect different project types. You can always say "use the project type guid" but that's dead wrong since you can mix certain projects, we don't want to block things unnecessarily. You could also check for a set of referenced assemblies but that just seems flaky. 

I do think we need this feature though. Do you have any thoughts on what kind of detection mechanism we could use?

Sep 22, 2010 at 3:43 AM

I am thought about the two options you just presented.  I think each method has a valid usecase.  For instance, my example actually depended on the api referenced.  Another scenerio would be that a package depends on some tooling api that is only available if the project type is installed. 

Coordinator
Sep 22, 2010 at 4:00 AM
Out of curiosity, why did you expect a package that explicitly calls out it's for "MVC 3" to work with "MVC 2"?

The reason I ask is that with the goal of simplicity in mind, it seems the simplest solution is to simply allow package authors to tag packages with pre-requisites and make sure to display that metadata in a prominent manner to the user so the user can make the right choice easily.

Not all prerequisites will be definable in such a way we can automatically determine whether they are met. Some prerequisites are vague such as "This package is really for those who are building a CMS solution" or "This package is for those who don't already have a DI container in use.".

I'm not opposed to having more technological solutions in the future for cases we can determine with 100% confidence, but I think for 99% of the cases, if I can tag a package as "MVC3", that's going to be good enough.

Now how do we show this metadata? In the Dialog, the answer is obvious. Show it in the right details pane. In the console, it'd be nice to show it when you list packages. Perhaps show it again in the output when you install a package.

Sep 22, 2010 at 4:11 AM
The answer to your first question.. Why did I do this.. It is because I was not paying attention to the version number. I say .MVCx on the end and did not even think about the specific differences between the version of MVC the project was using. It took a oh duh, this package was written for the new MVC.
 
I guess I am not trying to solve all the prereqs that could possibly exist, but rather make is easy to provide the 80% case. We have package dependencies figured out but, framework dependencies are not addressed yet.
 
Some of the examples you provided are not so much the dependency as much as they are the description or detailed about for the package.  It actually makes me thing of another feature which would be a hyperlink froma package to a more detailed explanation of the package.  I am thinking of a lnk from the Dialog as well as a hyperlink from the Console package name to the packages about or homepage.
 
 
 
Coordinator
Sep 22, 2010 at 4:23 AM

I still think this is a post v1 feature. The solution of just allowing people to tag packages with this information and trusting the user to make decisions should handle most cases and is cheap to implement. After all, you figured it out in no time and were on your way, right?

But I have put some thought into it before. One idea I had was to treat these pre-requisites like “implicit” packages. For example, perhaps a way to identify a project as MVC 3 is if MVC 3 project templates included a special “pre-installed MVC 3” package. Then in your package, you could define a dependency on MVC 3, but “MVC3” wouldn’t exist in the feed. Thus when you try to install that package, but MVC 3 isn’t installed, it would cause an error. Ideally, that package wouldn’t be an actually be a file anywhere in your project. Maybe it’s just some setting we place in the MVC 3 .csproj file.

Perhaps we could have a special “pre-requisite” dependency and not build this on package dependencies, but the general idea would be the same.

Of course, that doesn’t help us with older project templates. But we can build up a set of rules for different known project types and enforce the same pre-reqs.

Sep 22, 2010 at 4:38 AM
I agree this is a post v1 feature.  I think the implicit package concept sounds like a good approach. I think you should consider the assembly reference as well. For instance, I could have a package that extends wcf. so I would need the component model assembly referenced, in this case it would have need a specific project type but rather a system dependency.
 
 
On Tue, Sep 21, 2010 at 11:24 PM, Haacked <notifications@codeplex.com> wrote:

From: Haacked

I still think this is a post v1 feature. The solution of just allowing people to tag packages with this information and trusting the user to make decisions should handle most cases and is cheap to implement. After all, you figured it out in no time and were on your way, right?

But I have put some thought into it before. One idea I had was to treat these pre-requisites like “implicit” packages. For example, perhaps a way to identify a project as MVC 3 is if MVC 3 project templates included a special “pre-installed MVC 3” package. Then in your package, you could define a dependency on MVC 3, but “MVC3” wouldn’t exist in the feed. Thus when you try to install that package, but MVC 3 isn’t installed, it would cause an error. Ideally, that package wouldn’t be an actually be a file anywhere in your project. Maybe it’s just some setting we place in the MVC 3 .csproj file.

Perhaps we could have a special “pre-requisite” dependency and not build this on package dependencies, but the general idea would be the same.

Of course, that doesn’t help us with older project templates. But we can build up a set of rules for different known project types and enforce the same pre-reqs.

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Sep 22, 2010 at 4:47 AM
Ah yeah, some sort of special system assembly dependency. Perhaps still following the model I described earlier.
>
Sep 22, 2010 at 5:46 AM

Yes, I have thought about adding assembly dependencies as well.  There are two ways to look at this:

  1. Fail if that assembly is not referenced
  2. Add the assembly reference if it's not already there.  This would only work if it's available on the machine of course.

In any case, I think we're all on the same page that this is a post v1 feature.