views:

549

answers:

5

I have a annoying build process from using System.Addins API with ClickOnce. Using System.Addins requires a specific directory structure, and the main project does not reference the adapters, view, and contract directly, which doesn't work well with the ClickOnce architechture.

The annoying part with the build process is that I have to copy, via post build event, the .dlls from the add-in components into the directory of the main app project, then reference those files manually from the main project, so that ClickOnce will include them. Firstly, this takes 2 iterations of build to get it to build correctly, secondly, it interferes with source control (I have to exclude the copied add-in dll files from source control or any changes made to them would require checkout).

So, my question is, is there a way around this hack? Something more elegant?

A: 

ClickOnce do not let you install the software where you want. It will install the binary and dlls in the documents and settings. You can in your project properties go in the Publish tab and select Application Files to select additional file to Include. If the System.Addings require dll in a specific folder relatively to your assembly, you might just create the folder in you project and includes from here the dlls. This might works. If not, I do not have "hack" or other solution, clickonce is great but limited with some functionalities.

Daok
A: 

Thanks for your input, I am currently doing it the way you mentioned; creating the folder in my project, and include the dlls that I need. It works, but it's an ugly solution, and it interferes with Source Control.

I'm aware of the limitations of ClickOnce, I was hoping there may be a way around it. For example, I read somewhere that I can use deployment projects to create the appropriate dependencies needed in a specific structure. The problem with that is once it is deployed to the public, there is no easy way (within ClickOnce) to update those dependencies.

Metenas
since the order of posts isn't guaranteed to stay the same (reorders based on up and down votes), your reply to Daok would be better as a comment to his post rather than a new post.not trying to be critical, just want to help out SO newbies :).
whatknott
+2  A: 

I can't fully answer your question, but it appears you are creating ClickOnce deployments through Visual Studio. I would ditch that method and use MageUI instead. It's a stand-alone executable that can be found in the framework SDK that will generate your application and deployment manifest files. It comes with a gui version (mageui.exe) and a command line version (mage.exe).

Mage may not get rid of your post-build event but it should do away with having to reference the files to get ClickOnce to see them.

whatknott
A: 

The solution I use is to have a single output folder for all projects. Every project puts it's own files in the correct subfolder. The application bootstrapper project puts his dlls also in the output (root) folder. When you then create a click-ones for the bootstrapper, it will take all the content from the output folder.

The hardest part is to actually get all the dll's in the right place (and have every dll only once)

Profager
A: 

I solved this problem by adding the pipeline assemblies as content into the main solution structure.

To do this, change the output folder from (/bin/debug /bin/Release) to something else. I used ../lib otherwise you would get a visual studio cannot reference this file error.

Create the pipeline folders in your main solution

  • \AddInSideAdapters
  • \AddInViews
  • \Contracts
  • \HostSideAdapters

Right click on each of the folders and click "add existing item" change to view all files and then browse to your ../lib (or wherever you have the output set) and then pull down the add button (click the down arrow) and click "Add as a Link".

Right click on each file and set it to Content.

This will create a refresh file pointed to your assemblies and they will be included into the clickonce manifest.

AdamSane