views:

223

answers:

2

I have a VS 2008 solution with 2 projects. Project A builds into an assembly that is used by Project B (MVC project). I have created a custom task in Project A, which I call when building Project B.

I have come across 2 issues:

  1. If my AssemblyFile property points to Project A's bin directory, everything works well. But when I want to clean Project B, it always gives the error that Project A's assembly cannot be accessed because it is in use by another process (turns out to be devenv.exe) and the delete fails.
  2. If my AssemblyFile property points to Project B's bin directory, build fails saying that it cannot load or find Project A's assembly. I've triple checked the path, filename, uppercase/lowercase, spelling and also checked that Project A's assembly really is there when the build fails.

So what is wrong with scenario 1 and 2. Or where should I be pointing AssemblyFile to? Failing all that, is there a better way to do this?

+1  A: 

If you want to build the two projects independently of each other, then you can't reference the "A" assembly from the VS output directory where it's built to...

How I would handle this situation:

Create a dependencies folder at the top level of my projects folder in the trunk.. ie:

  • ~/trunk/dependencies
  • ~/trunk/projects
  • ~/trunk/projects/projectA
  • ~/trunk/projects/projectB

Then, in your build task for projectA, copy the assembly to the ~/trunk/dependencies folder once it has been built.

In projectB, reference that assembly in the ~/dependencies folder (so you generate a .refresh file)

This will allow you to clean projectB at will, and the "A" assembly will be brought down whenever you like.


For CI, we use JetBrains TeamCity and create artifacts for our builds, then the build tasks references those artifacts as needed.

datacop
>then you can't reference the "A" assembly from the VS output >directory where it's built to...Why not? The custom task is done after the build process after all the assemblies have been compiled and copied to the output directory. Or is this just another one of the gotchas?The only problem free way I could find was having the custom task in a separate assembly, Assembly C.I use CruiseControl.NET for CI. I have had a brief look at TeamCity and it seems that the UI is much better. But at the moment, CI is a bit of an overkill for a lone developer.
seanlinmt
+1  A: 

There are a few ways to define references on a project.

  1. A Project Reference - This is a more integrated approach as VS will determine the build order for you. So, when you build Project B, VS determines that Project B depends on Project A and will build Project A first and use the A's output dll from its output location. The drawback to using project references is that when you want to include your Project B in a different solution, you have to also include Project A.

  2. An Assembly Reference - You can also define a reference directly to an assembly. It sound like this is the method you are using. In this case, when you set a file reference from Project B to the ProjA.dll in /bin of Project A, Visual Studio doesn't know that it must first build Project A in order to create the ProjA.dll. You can instruct Visual Studio to first build Project A by setting the proper "Project Dependencies".

To do this, load up both ProjA and ProjB in a solution. Assuming you already have your assembly reference as you define in your scenario 2, right click project B and select "Project Dependencies...". Here, you just need to place a check next to Project A in the list. Now when you clean and build the solution, VS knows which order to build your projects.

It's also important to note that 'Build Order' and 'Project Dependencies' are defined at the Solution level. So, if you create a different solution with dependent projects defines as file references, you will have to set the build order for that new solution.

nick