views:

83

answers:

2

Hi There, I'm developing a .NET class library, along with some sample sources. So, My solutions consists of the library, the sample VB to illustrate the library, and a setup project to deploy it all.

The sample has a project dependency on the class library, and the setup project is configured to deploy the Class library (i.e. the output from the .NET class library project) and the sources of the VB app.

The problem is the vbproj file for the VB app contains the project dependency (i.e. it refers to the .csproj of the class library).

What I am trying to achieve is that when the sources are deployed on the client machine, it is a self-contained project, and it relies on the (just installed) class library DLL.

I suspect that I need to do some post install manipulation of the vbproj file, but as I'm new to this, am wondering if this (i would have thought) common issue is something I can handle easily?

TIA

+1  A: 

My suggestion would be to separate your two projects into two solutions- one for the library, and one for the VB sample project.

Your VB sample project could then just reference the library's DLL directly, instead of being a reference to the project. This is closer to how you plan to "deploy" this sample, so you won't need to do any manipulation after-the-fact.

While you're writing your library, this may be more difficult, since you'd be maintaining two projects, but if your library is mature, it's cleaner this way.

Reed Copsey
A: 

You could remove the "project dependency" and instead add an "assembly reference" to your VB project.

amit-agrawal
Thanks aamit, Reed. I knew both of the above options were open to me, but I really felt like that I had a reasonably common use case, that the environment would handle. I used aamit's suggestion. The build is now not as clean as such, but it does work.
dermdaly