 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Visual Studio.NET / IDE / May 2005ATL COM and C# Projects Coexisting in Same Solution
I have a situation with Visual Studio .NET 2003. I would like to have one solution to build all the projects associated with our release. This solution would contain a total of 60 projects, some are ATL COM projects, some are C# projects, and some are VB.NET projects. All the ATL COM projects have custom build events to register their outputs because other projects in the solution use those projects. When the solution contains only ATL COM projects and .NET projects that do *not* reference other ATL COM projects in the solution everything builds/rebuilds fine. As soon as I add a single .NET project that references one of the ATL COM projects in the same solution and I try to rebuild I get errors of the type: "ProjectName Could not delete file 'path\to\ProjectName.dll'. Make sure that the file is not open by another process and is not write-protected." ProjectName is one of the ATL COM projects referenced by a .NET project. This occurs for ATL COM projects that produce DLLs and for ATL COM projects taht produce EXEs. Currently I'm forced to divide up the projects into multiple solutions. If I place the .NET projects in a seperate solution from the ATL COM projects they reference then I can compile both solutions in the appropriate order to compile all the code. Although this works for now, my development team finds this annoying and we'd really like to have one solution to compile all our code for integration build purposes. Any ideas, comments, recommendations, etc. are welcome! -- Edwin Hi Edwin, >......, >my development team finds this annoying and we'd really like to have >one solution to compile all our code for integration build purposes. This behavior is by design, the a .NET project is opened in VS.NET 2003 IDE, it would prevent its referenced unmanaged COM dll being replaced/deleted. If you do not want to put the .NET application project in another solution, one possible workaround is to remove the .NET application project from the solution when you want to build some of the ATL COM DLL projects and add it back to the solution and then build it(if needed) at the end. You can do this task programmatically via VSMacro To remove and add a project to a solution, you can use the following method in the your VSMacro function: EnvDTE.solution.AddFromFile(...) EnvDTE.solution.Remove(...) Thanks! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights. Well, that is even more annoying! I can understand this behavior when I'm trying to reference third-party unmanged COM dll/exe. We would not want somebody messing with that. (Of course, it could be changed when the solution is closed... so what's the point...) We are developing both our unmanged COM assemblies and our .NET assemblies. We are slowly converting COM code to .NET where/when it makes sense. Our COM code is still evolving so it needs to get recompiled. We would like to be able to compile all 60 projects in one shot! Right now, since we need to seperate the projects into 3 solutions we need to do some wierd stuff to reference projects from other solutions! Anyway, thanks for the response. This lets me know that future versions of Visual Studio will work similarly and we'll need to figure out a better way to compile our code. In particular I'm tyring to plan for the build server in Team System and I'm guessing that we can't tell it easily to build three different solutions... I really want all this to be one solution, at least for the build server! -- Edwin Hi Edwin, I appreciate your understanding on this issue, currently it appears there is no good resolution to put your ATL COM and C# projects in a same solution without the build dependency problem. However. I will report your concern on this issue to our corresponding product team, this is a kind of feedback that let us know what things you're trying to do, that we haven't yet exposed for you, thanks! Have a nice weekend! Best regards, Gary Chang Microsoft Community Support -------------------- Get Secure! ¡§C www.microsoft.com/security Register to Access MSDN Managed Newsgroups! http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp &SD=msdn This posting is provided "AS IS" with no warranties, and confers no rights. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.