I am tasked with resurrecting a VB6 project and it has been too long since I worked with VB6.
Here is my problem.
Project A is an ActiveX EXE project. Within the same Project Group there is another ActiveX EXE project; Project B. Project B contains clsCommon (clsCommon.cls) that Project A needs to use, as in:
Private clsCommonA as ProjectB.clsCommon
When I attempt to add Project B's output exe (not the vbp) to Project A's references, I get the error Project 'Project B.vbd' can not be referenced because it's project type is EXE.
Can someone please remind me how to reference classes inside of an EXE? (I am having no trouble with referencing classes in projects in the project group where the output is a ActiveX DLL)
BTW: I assume this is even possible only because some developer 20 years ago evidently had this working.
VB6 does not allow you to add a reference to an ActiveX Exe (your ProjectB) from a project (ProjectA) that is loaded into the same IDE (project group). You get the error displayed when you try.
This is because an ActiveX Exe runs as a separate process, which I believe the VB6 IDE isn't capable of doing for separate projects in a group. So while it looks like you are adding the reference to ProjectB exe, since it's in the group, VB6 is actually adding a reference to ProjectB vbp, which isn't supported.
You need to remove ProjectB from your group. Then you'll be able to reference the ProjectB Exe from the ProjectA IDE.
If you need to run ProjectB in the IDE (for debugging or development), then first start VB6 and load ProjectB. Then start a second instance of VB6 and load ProjectA. When you start ProjectB, you'll notice that the reference in ProjectA changes from the ProjectB Exe to the ProjectB vbp (running in the second IDE). Set breakpoints in ProjectB as appropriate, then when you start ProjectA and instantiate ProjectB and make the method calls, you'll be running the ProjectB code in that IDE.
(NOTE - I've revised part of this)
As for the VB6 projects inside the group, you should be able to add mutual references to other projects in the group using the usual References window, EXCEPT TO EXE projects.
I tried this with a pair of test EXE / DLL projects, and when I try to add the EXE reference within a group I get an error:
(test1.vbp can not be referenced because it's project type is EXE.)
However I can reference the compiled EXE without issue from the DLL project. This may be your best way forward.
In order to register a compiled EXE, VB6 will do this for you when you compile it, but there was also a manual method which I eventually remembered - you need to run the .EXE itself using the /regserver switch.
Assuming that your .VBP already has the correct entries (basically, a reference line which points to the GUID of the EXE and/or some DLLs and OCX files) once you do this is should automatically find the classes in the EXE when you compile / run.
This is described in detali by several other SO questions so I won't repeat all that:
https://stackoverflow.com/a/211606/3195477
https://stackoverflow.com/a/4377190/3195477
https://stackoverflow.com/a/37931419/3195477
https://stackoverflow.com/a/1088289/3195477
https://stackoverflow.com/a/55459208/3195477
etc.
If you need to debug into the EXE from the group of DLLs, first make sure all the references are hooked up. Then you should be able to run the EXE project in the IDE, set breakpoints, and run the DLL group separately in another IDE instance and debug between them.
Related
I have written an application in Visual Studio 2013 that relies on a DLL called WSTP32i1.dll. Both the dll and its associated .lib file are included in the project and it compiles and builds without error. However, when I run it, I get this:
Putting a copy of the DLL in the application folder doesn't help. When I check the Solution Explorer, the DLL appears to be marked "Does not participate in build," which seems wrong but I'm not sure what to change it to.
Any suggestions?
Solution Explorer tree contains source files (cpp, h, rc etc.) used to build executables. Item Type property defines how this file will be processed. DLL is not a valid source file and IDE does not know how to process it. That is why it "Does not participate".
The standard (and the easest) way to link import library is to add reference to DLL project in Common Properties / References page of application project. By default, all DLL and EXE files of your solution are built in the same $(SolutionDir)$(Configuration) directory, so everything is ready to use without any adjustments and post-build events.
If your DLL is built in another solution, make sure that it is placed in the same folder as EXE file, or DLL's folder is specified in PATH environment variable.
I have 3 C# projects, A (WPF application), B (class library), and C (class library), such that A references B, and B reference C. Project C needs to call some native methods from a C++ DLL via P/Invoke. I added the native DLLs to the C# project and marked them a "Copy to Output Directory". When I build my solution, the native DLLs show up in the output directory for Projects B and C (correctly), but not for Project A. Is there a project setting that allows these to be copied by any project that ultimately references Project C (even if not directly)? Or do I just need to post-build event on Project A to copy this files to my application output folder?
I've looked at Dependencies of references not copied to output directory, but this was referring to project references, so I'm wondering if there is a solution in my case.
I also considered embedding the native DLLs as resources and modifying my DLLImport as in this MSDN article: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.dllimportattribute.dllimportattribute.aspx. But I get an E_ACCESSDENIED error (I've seen others with this same issue as well, as well as some concerns about triggering antivirus behavior when extracting the DLL to disk). I also noticed the article mentions linking the resource, rather than embedding it. Is this something I need to do as an MSBuild task, rather than through some project properties?
Worst case, I could just add a post-build event to my WPF application that copies the native files, but it would be nice if Visual Studio would recognize that these files should be copied.
I solved this by customizing the output for debug/release mode compiles (on the project properties window) so that all of my projects outputted to the same folder... Much like how an ASP.NET application is published where all DLLs end up in a single /bin folder. That fixed my issue.
Coming from a VS Setup project, where it automatically adds the dependencies within each project into the resulting msi, is there a way to do that in WiX as well?
For example project A references b.dll which exists in the GAC. It seems that b.dll is not being added to the resulting msi and it then crashes when the application is ran. Do I have to manually add b.dll as a component in the .wxs file or can it be done automatically like the VS setup project?
Thanks
From this link here, I've concluded that it's currently not possible to do it automatically in version 3.5
When building managed code Visual Studio correctly (and recursively) copies dlls of referenced managed projects to the output folder of the project being build.
However, if one the of those references is a managed DLL that depends on unmanaged dlls then these unmanaged DLLs are not copied to the output folder, even though their corresponding projects in the same solution and are listed as dependencies of the managed DLL.
I realize that this problem can be resolved by having all projects use the same output folder. We already do that for most projects, but we prefer to keep unit test output folders separate, causing the above issue for unit tests that use a managed Dll with unmanaged dependencies.
The solution we are using right now is a pre-build event to copy the necessary DLLs but this wastes time and is error-prone as it needs to be repeated for every project that uses the managed DLL.
I would therefore like to know if there is a way to get the build system to understand that it should always copy the unmanaged dependencies of the managed DLL whenever it decides to copy the managed DLL?
One workaround seems to be to add another node to the managed DLL project, naming the unmanaged DLL and setting the Build Action = "None", and Copy to Output Directory = "Copy if Newer".
Edit: For building a C++/CLR project, I think this would work:
Add the node, and set its build tool to Custom Build Tool. Then, in the Custom Build Step page, set the Command to copy $(InputPath) $(OutDir) and the Outputs to $(OutDir)\$(InputFileName). Looks like that should work.
I have a Visual Studio 2008 solution with two projects in it. A C++ DLL and a Csharp application.
The Csharp application uses [DllImport] to access the functions in the DLL, and has a dependency set on the DLL.
For some reason, setting the dependency isn't sufficient to cause VS to copy the DLL to the build path of the app. So the app project has a post-build event which causes the DLL to get copied. (If anyone knows of a cleaner way of doing this, please let me know!)
The problem I have is that when I make a change to the DLL code, then attempt to run the Csharp application in the debugger, VS2008 fails to realise that the DLL must be rebuilt (and re-copied).
I have to force a re-build of the Csharp application (ie by explicitly choosing build, or by "touching" a .CS file).
Does anyone know how to tell Visual Studio to do the right thing?
Edits:
I am using project dependencies. They aren't working correctly.
I am using a post-build event to copy the DLL across.
The issue is that, if you simply choose to debug the application, Visual Studio fails to recompile the changed C++ project, despite the fact that there is a dependency in place.
I know the dependency is working, because if I choose "Build" (as opposed to "Debug") the C++ DLL is built.
"Build" and "Debug" do different things. In Tools - Options - Projects and Solutions - Build and Run, there is a checkbox "Only build startup projects and dependencies on Run". This is checked by default. So, if VS isn't recognising the DLL as a dependency, it won't build it when you choose "Debug".
I don't have VS to hand (only Express), but you could try adding the C++ DLL as a reference rather than a dependency.
Hmm... so I haven't done this exact thing before but I just threw together a C++ lib project and a C# winform project in the same solution. I right-clicked the solution, chose Properties and then under Common Properties->Project Dependencies, I made the C# one depend on the C++ one.
When I make a mod to the C++ one, it will ask me if I want to rebuild the C++ one. There's a "Don't ask me" checkbox too.
Maybe my test is different than your situation, but it seemed to work when I did that.
Hope that is some help.
Assuming the DLL project isn't used in another solution, why not put the post-build event on the DLL app project, so it is always copied?
I've not tried, but can't you do this with the build order?
I have experienced this same issue with applications that have DLL project dependencies. It seems to me that the problem is that Visual Studio only launches the post-build event if it has to recompile something in the Application's project. So, if you modify the DLL source without modifying any of the headers that the Application includes, then the Application is not recompiled because from it's perspective the DLL is the same. Since the application is not recompiled, the post-build event is not triggered. So, the Application is left with out of date DLLs. I have yet to come up with a good solution to this problem.