5

Earlier this week I posted a question about how to effectively share files amongst multiple web applications within a solution. NuGet was offered as a solution and after some time I was able to implement a solution, but I have one issue that is currently blocking me from finishing it.

At this point I have two web application projects:

  1. Project.Common.Presentations
  2. Project.Website.Presentations

Each time the Project.Common.Presentations project is build, a new NuGet package with a higher version is created. This package is used in my main web project Project.Website.Presentations. Initially I add the project.common.presentations NuGet package to this project through the GUI. Right after that I setup a pre-build eveny where I do a NuGet update from the command line to pull in the latest version of the Project.Common.Presentations package.

But somehow using NuGet update in the command line adds a reference to my project using a location that’s not actually on disk, leading to this issue:

Could not resolve this reference. Could not locate the assembly "Project.Common.Presentations". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

This is how I set up the structure:

  • I generated a NuSpec file for my Project.Common.Presentations project using the .csproj file.
  • As a post-build event in my Project.Common.Presentations, I use: $(ProjectDir)nuget.exe pack -sym $(ProjectPath). This builds a new NuGet package every time the project is build. Before this build-event is executed I use a script to delete the old NuGet packages.
  • As a pre-build event in my Project.Website.Presentations I use: $(ProjectDir)NuGet.exe update $(ProjectDir)packages.config

The first rebuild all is run, my .csproj file is updated with a dll reference to my package, all is fine and good. The second time I run rebuild all, the .csproj file is updated again, but it references a different folder with a newer version of the package but the folder somehow is not on the drive. When I use the GUI "Manage NuGet packages" to update the NuGet package this problem does not occur, everything works fine.

Removing the pre-build event, and updating the package manually works fine. But having to do something manually each time you build is not something I enjoy. Using the Package Manager Console to uninstall and install the package also works fine. Is there a way to incorporate Package Manager Console action into a pre-build event? Thanks in advance for the information.

Community
  • 1
  • 1
Oskar
  • 333
  • 4
  • 16
  • It would be helpful if you posted the pre-build command that isn't working for you. – Jim Counts Jun 02 '12 at 13:09
  • What common functionality needs to be shared that can't be put in a library project? – IrishChieftain Jun 02 '12 at 14:35
  • @IrischChieftain: in the long run i want to create functional application components inside the different web projects, so i want to package the entire web project (master pages, aspx pages, scripts etc) and bring everything together in the main web application. – Oskar Jun 02 '12 at 15:07
  • I think this can be done using a combination of NuGet and library projects without relying on build scripts; see my answer. – IrishChieftain Jun 02 '12 at 15:11
  • @JimCounts I updated my post with some more details on the setup. – Oskar Jun 02 '12 at 15:17
  • @IrishChieftain: Could you be a bit more specific on how to do that. Is it possible to package MasterPages and Aspx pages inside a library project and still use them like you normally would in the main application? The aspx pages have to actually be in the project right? – Oskar Jun 02 '12 at 15:21
  • Try it and see? For me, the master page was shared and built successfully at the level of each project - clincher will be the page attributes... I haven't tried it myself... – IrishChieftain Jun 02 '12 at 15:38
  • To my knowledge the aspx pages must exist in the project. For instance, you have an about.aspx page, the page must live inside the project as a file otherwise calling http://localhost/about.aspx will return 404. – Oskar Jun 02 '12 at 18:09

1 Answers1

2

The basic idea of using NuGet for something like this is to share the relatively static (seldom changing) artifacts among all the projects in your solution. I personally used NuGet to also include a common master page - all my files went in the NuGet Content folder.

All my common functionality went in library projects, which obviated the need for build scripts of any kind.

Ref: Multiple web applications projects within a visual studio solution

Community
  • 1
  • 1
IrishChieftain
  • 15,108
  • 7
  • 50
  • 91
  • When only having to share one master page that does not change often i would have opted for that approach as well. But If i have a project with about 10 aspx pages that do change frquently, how would i share those across projects? Is NuGet still a valid option or would another approach be more valid? – Oskar Jun 02 '12 at 15:28
  • Since iam planning for this projects there are no actual pages yet. In all my current projecti place all the "normal" things in my aspx files (html template code and references to controls etc.). I keep all my C# code in the code behind. – Oskar Jun 02 '12 at 16:11
  • I see no scenario where you need to share pages across Web projects - sections of pages that are common can go in the master page? You also have the option of user controls. – IrishChieftain Jun 02 '12 at 19:41
  • 1
    If you want to split your application into logical components those components will most likely have their own aspx pages. After trying different approaches i have to agree that NuGet is by far the best approach when you deal with stuff that doesn't change regularly. However, when still in active development I prefer adding a reference and using a post-build event to copy over any files that do not get compiled (frond-end code, aspx page front-ends, master page front-end). @IrishChieftain thank you for all the help you have provided for my two questions, it is much appreciated. – Oskar Jun 02 '12 at 20:04