3

I have several Visual Studio web application projects that include SVN externals. When a new file is added to an external module, VisualSVN brings it down to the file system, but doesn't add it to the Visual Studio project; it has to be manually added.

I might write a macro to automate this process, and I'm wondering if I can make it a one-step process by either:

  1. Having the macro initiate the VisualSVN update, then do the work (Q: Is it possible to trigger a VisualSVN update from a macro?)
  2. Hooking into a hypothetical "post-update" event from VisualSVN to fire a macro to do the work (Q: Does such an event exist?)
Herb Caudill
  • 50,043
  • 39
  • 124
  • 173
  • I know that many people feel strongly that svn:externals are a Bad Idea - hopefully we can save that discussion for another thread. Thanks! – Herb Caudill Dec 21 '09 at 20:38
  • 1
    Wouldn't the effort of integrating an externally referenced project into your code outweight the tiny cost of adding the project to your solution by several orders of magnitude? It should only have to be done once when you introduce the external reference, and then you check in your updated solution along with the external ref. Am I missing something? – Marcelo Cantos Dec 21 '09 at 20:44
  • Are you basically trying to have it perform a `Show All Files` command and then add all the items that are not part of the project to it? – Agent_9191 Dec 21 '09 at 20:49
  • @Agent_9191: Yes. Although I haven't written the macro to do this, I imagine there's not much to it. What's unclear to me is how to tie this to the SVN update process. – Herb Caudill Dec 21 '09 at 22:26

1 Answers1

1

I assume you are currently working like this: your "external modules" are just a loose collection of source files without a project file. Whenever a source file is added, you update all your application project files by adding the new source file, so that it is compiled into all the application assemblies.

I think you are doing it wrong. Your project solution file should contain a reference to a separate visual studio project file for each external. Each source file should be compiled into exactly one assembly.

For example, you might have a C# library shared between multiple web applications. This library has its own .csproj project file, which lives in the external location. If a source file is added to the library, the .csproj is updated. The updated .csproj file is then pulled it via an svn:externals declaration when you update your project.

Wim Coenen
  • 66,094
  • 13
  • 157
  • 251
  • Thanks. For the purposes of this question, can we take this architecture as a given? There are a number of reasons why this pattern works better for us than one-project-per-module, which I'd be happy to go into elsewhere. – Herb Caudill Dec 21 '09 at 22:24
  • @wcoenen - maybe in this question: http://stackoverflow.com/questions/530062/is-wcsf-for-me – Herb Caudill Dec 22 '09 at 16:54