I have a main executable that runs based on settings saved in a configuration file. I want to be able to change the settings in the config file through a different executable.
Is there an easy way of building these two different executables in one Windows Forms project? Meaning that when I press build, two different EXE files get created in the same solution folder - the one that changes the configuration file, and the other that uses it.
I know that this is possible to do if I create two separate projects that use the same solution folder, but I was hoping to do it all in one step.
I am assuming that to do this, I need a project with two "Main" functions. Is this possible?
You can build as many assemblies in one solution as you like. Assemblies can result in DLL files or EXE files.
Create a solution (or open an existing solution).
Right-click the root node in Solution Explorer and choose Add → New Project and choose the project type you like to add.
Right-click the project item in Solution Explorer and choose Properties → Build → Output path. Set to the desired directory where to build it to. Repeat this for the other projects.
This way you get the following in Solution Explorer:
MySolution
MyCommonCode (Class Library, results in MyCommonCode.dll)
MyMainApp (Windows Forms application, results in MyMainApp.exe)
MyConfigApp (Windows Forms application, results in MyConfigApp.exe)
The MyCommonCode assembly contains shared code that both EXE files are using like the identifiers of your configuration file, etc.
MyMainApp is the GUI application (Windows Forms, WPF, etc.) for your main application with a project-reference to the MyComonCode project.
MyConfigApp is a GUI application for editing the configuration values with a project reference to MyCommonCode project.
After building your solution you get the following binaries: MyCommonCode.dll, MyMainApp.exe, and MyConfigApp.exe.
Update based on the comment:
One compile-run can build only one binary (DLL or EXE) per project. You can do something like the answer above: move most of the code in a common/core DLL and make two thin projects for the two EXE files which only "configure and use" the central common/core DLL file.
You can build different EXE files based on the same project using compiler defines. You can even define your own defines. But per compile-run you can only build one binary (DLL, EXE) per project - one or the other, but not both.
Related
Help needed! I am new to IIS Administration and trying to host my ASP.NET Web Application.
My Web application looks similar to the one below:
I want Parent, Child-One and Child-Two to run as separate Applications and can be accessed as parent.com, parent.com/child-one and parent.com/child-two respectively.
The reason why I opted for this Project structure is to check if it is possible to Re-use some libraries present in Bin folder of Parent in Child-One and Child-Two.
Is it possible to re-use some DLLs from Bin folder in Parent, inside Child-One and Child-Two, Or do I have to create 3 separate projects?
You show a single project with some folders inside. The location of bin folders is not very relevant. More important is that there is only one References node (as with every .NET project), and whatever you add there is available for the whole project. You do that with Right-Click + Add Reference...
You don't need the separate bin at subfolder level, but if you insist on placing DLLs there then it will also work, as long as you set Copy Local to True in the References node (meaning that on Build the referenced DLL is copied to the output folder).
Visual Studio itself will always default to working with the root bin, e.g. if you add NuGet packages, then that is where their DLLs go, and you shouldn't mess with that.
I am new in mvc and c# and I can't solve following problem:
I am trying to create a folder named "Items" in solution folder.
I have tryed to use CreateDirectory method:
Directory.CreateDirectory("~/Images");
But it didn't work for me - folder wasn't created ..
Partly working solution was to create a folder by :
Directory.CreateDirectory(Server.MapPath("~/Images"));
"Items" folder was created, but it is not included in the solution:
How to create folder in solution directory so that it is included in project ?
(I needs to by done by code not by hand)
You need to understand what solution and csproj file is used for
In general, they're being designed and used for development with Visual Studio, and once the project is compiled, all these files will be ignored and excluded from the deployment package
Directory.CreateDirectory(Server.MapPath("~/Images"));
The code above simply create the directory if not existed yet in the deployment package at run-time, so you won't see it in your solution unless you run the project locally (either debug/release mode, it does not matter here). However, everything will run normally in hosted environment (ex: IIS).
For your information, here's the brief of what solution and csproj is
solution (.sln) file: contains information to manage one or many individual projects, contains build environments (for each project), start up mode (useful when you want to start multiple projects in one run), project dependencies and so on. Take a note that VS also read from suo file (solution user options) which is used to defined user-custom preferences (you should not include the .suo file in the version control, because it's custom settings)
csproj file: define the structures of project, what the namespace is, what is static folders, embedded resources, references, packages, etc.
Lastly, if you create the folder manually, VS will auto include that folder into deployment package AND csproj, but depends on the file type, you might need to change the Build Action and Copy To Output Directory in file properties.
Hope it helps.
A deployed web application on a web server doesn't have any notion of Visual Studio solution or projects. So the Directory.CreateDirectory(Server.MapPath("~/Images")) is the correct way to create a folder inside your web application at runtime but we cannot be talking about including it into a solution because this hardly makes sense in a pre-compiled web application. If you create the directory on your local development machine, you could always manually include the folder to the corresponding .csproj file, but at runtime this will not make any difference whatsoever.
The reason I wanted to create a folder (if didn't exist) was to make sure it exits before I try to store image in it.
After reading posts here and a few google searches I have concluded that the proper way to handle image upload would be
To create (In my case) folder "Images" by hand to be sure it exists
Then storing uploaded img in existing folder:
string path =Server.MapPath("~/Images/"+ UploadedImageName);
file.SaveAs(path);
We have a solution comprising of a windows application and various library files. Not all of the library files are referenced by the main windows application however we would like to have all the library files included in the output build folder "bin".
Obviously one solution is to simply reference every single library from the Windows application however we would like to avoid any unnecessary referencing.
How can we include additional files into our build folder?
This is a C# project.
You can always use the pre-build or post-build events in the project settings to copy the additional files.
You can do this simply by doing a bunch of copy source target, or you could even be fancy and write an nmake file. You do have to maintain the list of source files however...
Edit:
One other thought. Your assumption is that this is "unnecessary referencing". However, if your application depends on these assemblies to run, whether or not they are compile time references, then don't these dependencies become "necessary" references? In that case, isn't adding them as references and letting Studio's build system work for you the best (and simplest) approach?
The solution was to change the build location for all "libraries" within the solution to the main output "bin" location. The main Windows application only references the libraries that it depends upon however all the libraries are built to the one "common" location.
Thanks to Nader Shirazie for help with this question.
I have a solution which has 3 projects. One is a console app and other 2 are windows applications. Both windows applications uses console application so I added the reference of console application in both windows app projects. Now when I build windows projects, console application is being copied in output directory but the problem is that its config file "consoleapp.exe.config" is not being copied!
If I would have used a library (assembly) instead of console application, it would created the config file of that assembly in output folder.
How to solve this problem?
Try this:
Select consoleapp.exe.config in solution tree.
Select "Content" for Build Action option in property grid.
Select Copy always for Copy to Output Directory option.
Hope this helps you :)
Quickly creating a console project in VS2008 and adding an "App.config", it has settings:
Build Action: None
Copy to Ouput Directory: Do not copy
Custom Tool: <blank>
Custom Tool Namespace: <blank>
However I'm not sure what effect adding a reference to the console project will have, as a console project is an application rather than class library.
If you want the console application to start up with the Windows applications for debugging, then a better approach than project references would be to set the solution to start multiple applications. Right click on the solution, select properties and on the Start Project node, select multiple projects. (And remove the references to the console application.)
Your applications are using the default values for your settings from the compiled code of the referenced project.
You should copy your app.config from the other projects (or at least copy the settings that you want to be able to change) to the calling project, and then when the application compiles you will have an [YourAppName].exe.config that you can modify.
All this happens because an app domain in C# can have only one assembly level app.config file. Here's more information on MSDN.
I have a annoying build process from using System.Addins API with ClickOnce. Using System.Addins requires a specific directory structure, and the main project does not reference the adapters, view, and contract directly, which doesn't work well with the ClickOnce architechture.
The annoying part with the build process is that I have to copy, via post build event, the .dlls from the add-in components into the directory of the main app project, then reference those files manually from the main project, so that ClickOnce will include them. Firstly, this takes 2 iterations of build to get it to build correctly, secondly, it interferes with source control (I have to exclude the copied add-in dll files from source control or any changes made to them would require checkout).
So, my question is, is there a way around this hack? Something more elegant?
I can't fully answer your question, but it appears you are creating ClickOnce deployments through Visual Studio. I would ditch that method and use MageUI instead. It's a stand-alone executable that can be found in the framework SDK that will generate your application and deployment manifest files. It comes with a gui version (mageui.exe) and a command line version (mage.exe).
Mage may not get rid of your post-build event but it should do away with having to reference the files to get ClickOnce to see them.
Thanks for your input, I am currently doing it the way you mentioned; creating the folder in my project, and include the dlls that I need. It works, but it's an ugly solution, and it interferes with Source Control.
I'm aware of the limitations of ClickOnce, I was hoping there may be a way around it. For example, I read somewhere that I can use deployment projects to create the appropriate dependencies needed in a specific structure. The problem with that is once it is deployed to the public, there is no easy way (within ClickOnce) to update those dependencies.
The solution I use is to have a single output folder for all projects. Every project puts it's own files in the correct subfolder. The application bootstrapper project puts his dlls also in the output (root) folder. When you then create a click-ones for the bootstrapper, it will take all the content from the output folder.
The hardest part is to actually get all the dll's in the right place (and have every dll only once)
I solved this problem by adding the pipeline assemblies as content into the main solution structure.
To do this, change the output folder from (/bin/debug /bin/Release) to something else. I used ../lib otherwise you would get a visual studio cannot reference this file error.
Create the pipeline folders in your main solution
\AddInSideAdapters
\AddInViews
\Contracts
\HostSideAdapters
Right click on each of the folders and click "add existing item" change to view all files and then browse to your ../lib (or wherever you have the output set) and then pull down the add button (click the down arrow) and click "Add as a Link".
Right click on each file and set it to Content.
This will create a refresh file pointed to your assemblies and they will be included into the clickonce manifest.
ClickOnce do not let you install the software where you want. It will install the binary and dlls in the documents and settings. You can in your project properties go in the Publish tab and select Application Files to select additional file to Include. If the System.Addings require dll in a specific folder relatively to your assembly, you might just create the folder in you project and includes from here the dlls. This might works. If not, I do not have "hack" or other solution, clickonce is great but limited with some functionalities.