Designer Assemblies

May 5, 2011 at 6:09 PM

If you deploy a component which has an assoicated designer Visual Studio requires that the designer assembly be located in the same directory as the component.

If I deploy the component and designer with NuGet, the target project gets references to both assemblies.

In this case, the target project should not have a reference to the designer assembly.  It is required only for design time support.

Is there a way I can deploy the designer assembly with NuGet and *not* have the assembly reference added?  Remember it must be in the same directory as the runtime component.

If there is not a way, I suppose I could *remove* the reference that NuGet added from a script.

 

 

May 5, 2011 at 6:42 PM
Long ago requested, highly voted, still unimplemented.

http://nuget.codeplex.com/workitem/263
May 5, 2011 at 8:13 PM
Edited May 5, 2011 at 8:14 PM

+1 on that feature. I have the exact same requirement.

Please vote up the workitem Brad links to.

Note that it doesn't have to be in the same folder as the assemblies, but can be in a \Design\ sub-folder as well.

At least with Silverlight, VS2010 is smart enough to detect it can't reference these assemblies and removes them again, however WPF and WP7 projects aren't that smart.

May 5, 2011 at 9:08 PM
Edited May 5, 2011 at 9:09 PM

One simple possible approach to this problem is to follow a naming convention to hint to nuget that it should not add a .dll as reference. For example, those assemblies can be named as A.dll.noreference. When nuget installs the package, it simly removes the .noreference extension and just copies to the assembly as is. This would work nicely with satellite assemblies too.

Note that this is consistent with the way we treat transformation files. Those files have .transform and .pp extensions.

May 5, 2011 at 9:31 PM
Too many possible complex issues with this approach IMO. Especially for other clients (like openwrap). I think I would rather have a bit more added to the nuspec for files not to have referenced (since by default I would add all).
May 5, 2011 at 9:37 PM
Edited May 5, 2011 at 9:41 PM

So is the goal to have those assemblies not be referenced, but still end up in the bin folder at build time? If so, something is going to have to copy it there (e.g. via some build action), as it won't happen magically.

Coordinator
May 5, 2011 at 9:58 PM

ok, last time.

Ok, sorry for the confusion. I misread the scenario. Let me try again. :)

Well I think we have 3 scenarios here:

  1. Designer: You have a set of assemblies that should not be referenced, and should not be copied to bin. 
  2. xUnit: You have a set of assemblies that should be referenced, but from a directory other than lib.
  3. Runtime only assemblies: You have a set of assemblies that should not be referenced, but should be copied to bin.
Coordinator
May 5, 2011 at 10:00 PM

By the way, I started a mini-spec to capture any decision points and summarize this discussion. I appreciate your help in trying to think these scenarios through: http://nuget.codeplex.com/wikipage?title=Allow%20Specifying%20Unreferenced%20Assemblies

May 5, 2011 at 10:03 PM

Here is an Install.ps1 that will remove the reference - it's a good workaround for now

param($installPath, $toolsPath, $package, $project)

#remove the designer
$ref = $project.Object.References.Find("Microsoft.Activities.Design")
if ($ref) { $ref.Remove() }


May 5, 2011 at 10:41 PM

@haacked: thanks for clarifying the scenarios. My concerns that we have many people saying they want this feature when in fact not every one is looking for the same things at all.

@ronjacobs can you confirm that in your scenario, you do not want the assembly to end up in the 'bin' folder at all? So that means it will only exist in the NuGet Packages folder. How will anyone find it there?

May 5, 2011 at 10:55 PM

The design assembly is only required at Design time with Visual Studio.  It does not need to be referenced or deployed at runtime, however, Visual Studio extensibility mandates that it be located in the same directory as the runtime assembly.

I'm using a Powershell script to add toolbox items for Workflow Activities.  At design time, the user will drag/drop toolbox items onto the Workflow Designer surface.  Visual Studio knows that the toolbox item is referring to a class in Microsoft.Activities.dll which is in the packages folder.  It will then look for Microsoft.Activities.Design.dll and if it exists, will load it and the associated designers will appear.

Coordinator
May 5, 2011 at 10:56 PM

So this fits under the scenario where there are assemblies in the lib folder which are not referenced and not copied to bin.

This is similar to the xUnit scenario, but not the same thing.

May 5, 2011 at 11:07 PM

So for all practical purposes, you want NuGet to completely ignore this assembly, right? It'll be a DLL under 'Packages\SomePackage.1.0.0\lib', but NuGet should act as if it isn't there at all. Correct?

May 5, 2011 at 11:22 PM

Yes, that is correct. 

May 12, 2011 at 1:44 PM
haacked wrote:

Well I think we have 3 scenarios here:

  1. Designer: You have a set of assemblies that should not be referenced, and should not be copied to bin. 
  2. xUnit: You have a set of assemblies that should be referenced, but from a directory other than lib.
  3. Runtime only assemblies: You have a set of assemblies that should not be referenced, but should be copied to bin.

For me VS already handles correctly cases 1) and 3) : if the library referenced requires additional assemblies located on the same lib folder, then these dependencies are copied along with the main assembly when compiling your project. But if the assembly is not referenced at all (as it's the case for .Designer assemblies), VS will never copy them to the output directory.

A single attribute in the <file /> element could handle all of these : for example "reference" which defaults to true when target="lib" and false for other targets. (It will allow to handle case 2) also l <file src="xUnit.dll" target="tool" reference="true" />).

It will allow to deploy additional assemblies in the lib folder to provide optional features that the developer could reference directly beside the main references.

NuGet will only use this attribute value to choose if the library must be added as a reference in vs or not (+ the extension type in case of <file src="MyLib.pdb" target="lib" />)

Also, should the package allow to specify the "Copy Local" and "Specific Version" property from the referenced assembly ? I don't know. For me it doesn't seems necessary. It could help to handle cases where you want to add the library as a valid reference but doesn't want it to be deployed.

Mar 14, 2012 at 3:51 PM
Edited Mar 14, 2012 at 3:55 PM

I had some issues related to this topic, and maybe my solution at this thread could help. (Please refer to Message 26)