WPF and Console Application EXEs in same solution
Asked Answered
B

3

6

I have a WPF application that is going to be installed on several client PCs. I'm using InstallShield Express Edition as the deployment tool for that.

I've created a different project(DLL) to keep track of the software installations. Basically is a stand-alone C# project that reads, writes and does some validation checking in the Windows Registries, and can be integrated in other WPF applications (this project/DLL is going to be useful for other Apps).

What I want to do is to create an .EXE file to register the installation. This .EXE is not used in the main WPF application, but uses the .DLL that I've just talked about above.

I've managed to do that by creating a different solution with a single Console Application project, and referencing the necessary DLL's. But what I really want is to create it as project within my Main App Solution, and when I do that no .EXE file is generated other than the Main App executable.

Is there anything I can do to get the 2 .EXE files (Main App and InstallationRegistration) or is the way I'm currently using the only way?

This is more a nuisance than a problem, but still... it will be a better way to keep track of this small module in all the different Applications I've developed.

Thanks

Biernat answered 15/12, 2014 at 12:23 Comment(1)
What are you using for building the solution? VS should not have problem building different projects each with it's own executable.Limonite
C
0

By default, all intermediate compilation artifacts are placed in the obj folder under a given project in the solution (so far I am not aware this can be changed).

For project outputs they are, by default, put under bin\Debug or bin\Release depending on your Build Configuration.

This can however be changed from the Project's Properties; specifically the Build tab has an "Output path" option for you to specify the build output location.

This has to be done on a per project basis but I generally create a SolutionDir\bin folder under the Solution root and direct all project output paths to SolutionDir\bin\Debug or SolutionDir\bin\Release as the case may be. This has the added advantage or reducing the total size of SolutionDir by avoiding multiple copies of output assemblies in large solutions with complex interdependencies between projects.

Does this help?

Chadbourne answered 15/12, 2014 at 20:10 Comment(1)
Yes... it actually does. There were a bunch of repeated .DLL's being created on the second output folder. And all I need is my .EXE. This way prevents the creation of all that extra "garbage". Thanks a lotBiernat
C
1

Are you saying the Console EXE is not created as part of the build/run of the solution?

Or the Console EXE is not created as part of the InstallShield deployment project?

If you are referring to building Console EXE as part of the build/run of the solution:

Generally, when you hit F5, Visual Studio builds only those projects you designate as Startup and their dependencies.

You will have to explicitly build that Console App or the Entire Solution.

You can designate it as one of your Startup projects if you want it to be built everytime you hit F5; or specify it as a dependency of the MainApp project (that's a bit of a cheat but it gets the job done).

Chadbourne answered 15/12, 2014 at 12:40 Comment(1)
Just posted the solution... only got there by reading your answer. It got me thinking about going to check the debug folder on the application folder. ThanksBiernat
B
1

After trying for a few different ways I got to that DUH!!! moment.

What happened is that VS was creating both .EXE files for the Main App and the Console Application, only with each one is in their respective Debug/Release Folder

For Example:

Main App -> C:\Projects\MyApp\MyAppUI\bin\Debug\MyAppUI.exe

Intallation Control.EXE -> C:\Projects\MyApp\InstControl\bin\Debug\InstControl.exe

NOTE: C:\Projects\MyApp is the solution folder.

It kinda makes sense they are on their own folder, but on the other hand, there should be an option in VS to choose where we want to send all the solution's .EXE

Hope it helps someone in the future.

Biernat answered 15/12, 2014 at 14:38 Comment(1)
You can actually set the build output path from the project properties. I generally dump all dll's and exe's in the same folders under the solution root. For instance, $(SolutionDir)\bin\Debug or $(SolutionDir)\bin\ReleaseChadbourne
C
0

By default, all intermediate compilation artifacts are placed in the obj folder under a given project in the solution (so far I am not aware this can be changed).

For project outputs they are, by default, put under bin\Debug or bin\Release depending on your Build Configuration.

This can however be changed from the Project's Properties; specifically the Build tab has an "Output path" option for you to specify the build output location.

This has to be done on a per project basis but I generally create a SolutionDir\bin folder under the Solution root and direct all project output paths to SolutionDir\bin\Debug or SolutionDir\bin\Release as the case may be. This has the added advantage or reducing the total size of SolutionDir by avoiding multiple copies of output assemblies in large solutions with complex interdependencies between projects.

Does this help?

Chadbourne answered 15/12, 2014 at 20:10 Comment(1)
Yes... it actually does. There were a bunch of repeated .DLL's being created on the second output folder. And all I need is my .EXE. This way prevents the creation of all that extra "garbage". Thanks a lotBiernat

© 2022 - 2024 — McMap. All rights reserved.