I have various small apps which I would like to to gather under a new application where they can all be accessed from one "exe" file. I have merged the projects into a solution called "ETABS SUIT" and referenced the projects.
I was expecting and hoping to have just one executable file in the debug folder when I build the solution, but it seems like all projects are built separately with standalone exe files.
Is there a different way to combine all my projects under a new solution and get a single exe file when built? (It may be also okay if I can check a boolean value provided in the main solution before starting the other projects but what I define in the main solution is not recognized in added projects)
Related
I have a large solution with a lot of different libraries in and they are used in various solutions. Is it possible to obfuscate and replace the Dll directly before they are copied to projects that reference them, instead of using a separate directory as output?
I am writing a very basic library in VB.NET
The library just contains classes and modules.
Now in built output I see this files
Application.Designer.vb
Application.myapp
AssemblyInfo.vb
Resources.Designer.vb
Resources.resx
Settings.Designer.vb
Settings.settings
Since I've seen other libraries with only AssemblyInfo.vb file, I was wondering if I can delete the rest.
What is the minimum of files I need here for the lib to work correctly, since I don't have any ressource or setting?
All the files you listed are necessary for a vb.net library project. And these files are generated (in My Project folder) when the project created not the build output files. So you need to keep all the files you listed in order to develop and build your project locally.
And for the files of build output, you can add these files in .gitignore.
When you create a project in VS, you select a predefined template that dictates what gets created. People often become accustomed to seeing the superfluous objects that a given template creates and assume that those objects are mandatory and must be there, However, much of it is not needed.
There is also the Empty Project template (the exact name of this template varies depending on the VS version used).
In VS2017, selection of the template would look like this:
This is a bare-bones project and the Solution Explorer will look like this:
As you can see, there are no pre-loaded references. You will need to add them yourself. About the only thing defined in this template is that you are using the VB language; This project starts out as a WinForm type, so go to the Project Properties->Application tab and change the "Application type" to "Class Library" since you want to create a library.
You may find it useful to start with an Empty Project and add the stuff you normally use and then export the project as new template (in VS2017: Project Menu->Export Template). For more on creating termplates, see: Creating Project and Item Templates
Edit: I just realized that I did not answer your real question about deleting the unused items. I just did a test case and deleted the items under MyProject. I received an error on deletion, but doing a clean/rebuild allowed me to proceed without issues. I would recommend that you backup the project before attempting this on an existing project, but I saw no long term issues in deleting unneeded objects from MyProject.
I am new to Android Studio and trying to understand how it works. I have a project which is a mixed code base (C++ and Java) and trying to convert that to an Android Studio project.
As of now, I am building my app from command line because my app is currently not using any IDE, it is made up of multiple folders. I was wondering if I should be structuring my project such that every module creates a .so file? In another words should I have:
One module and multiple folder under it
Multiple modules
Does every module create one .so file or multiple .so files?
This depends on the size and complexity of your project. One advantage of having multiple shared libraries (.so files) is that if you make binary-compatible changes in one area of the codebase, you don't have to recompile your entire project. You can just rebuild the module which you made changes in, and the dependent modules will link to the updated library.
If your project is quite large and rebuilding everything takes a long time, this can be a big timesaver. If you want to be able to reuse certain modules in other projects without having to pull in all the code from this project, it would make sense to separate into modules.
Splitting your C++ code into multiple modules does add some complexity to the build (and the syntax to specify C++ builds keeps changing on top of that), so you'll want to take that into account when you decide.
I am building a project on Github written in Objective-C. It resolves MAC addresses down to manufacturer details. The lookup table is currently stored as text file manuf.txt (from the Wireshark project), which is parsed at run-time, which is costly. I would prefer to compile this down to archived objects at build-time, and load that instead.
I would like to amend the build phases such that I:
Build a simple compiler
Run the compiler, parsing manuf.txt and outputting archived objects
Build the framework
Copy the archived objects into the framwork
I am looking for wisdom on how to achieve steps 1 and 2 using Xcode v7.3 as Xcode provides only a Copy Files phase or a Run Script phase. An example of other projects achieving similar goals would be inspiring.
I suspect that what you are asking is possible, but tricky. The reason is that you will need to write a bunch of class files and then dynamically add them to the project.
Firstly you will need to employ a run script phase to run various tools from the command line to parse your file and generate a number of class files from it. I would suggest looking into various templating engines. For example appledoc uses moustache templates to generate API documentation files. You could use the same technique to generate header and implementation files.
Next, rather than generating archived objects an trying to import into a framework. I think you may be better off generating raw source code, adding it to a project and compiling into a framework. Probably simpler in the long run.
To automatically include the generated code I would look into (which means I haven't actually tried this :-) adding a folder reference to the project rather than an Xcode group. Folder references are an option in the 'Add files to ...' dialog.
Folder references refer to a directory and automatically add the entire contents of that directory to a project. So you can use one to point to the directory where you have generated the source code. This is a much better option than trying to manipulate the project or injecting things into an established framework.
I would prefer to parse the file at runtime. After launch you can look for an already existing output, otherwise parse it one time.
However, I have to do something similar at Objective-Cloud. I simply added a run script build phase and put the compiler call into it.
Situation: An application, that is built into several variations, with different functionality enabled. Each variation has its own main project, with its own output "bin" folder. Call the variations A and B.
There are various common class libraries, which generate dlls. Those all get automatically copied to both output folders. This is working fine.
Now, add another project. It generates an exe, C.exe. It will be loaded as a separate process by the application. (It creates a NamedPipe, providing a ServiceContract via NetNamedPipedBinding.)
When there was only "A" (no "B"), I simply had A and C specify the same output folder.
But now there are TWO places that C needs to go.
For Debug build, must go to A/bin/Debug and B/bin/Debug. Similar for Release build.
The source language is VB, but an answer based on C# projects would almost certainly be adaptable to my situation.
I've written an answer by using XCopy in Post Build Events.
Looking for alternative answers.
Is there a way that is easier to maintain / not dependent on manually entering paths?
My concern is that as variants are added, or moved around, it is necessary to know about the Build Events and manually edit them.
Doing work for a company that is not great at keeping track of such details over the years.
Looking for a way that is less likely to break, or easier for a junior programmer to maintain.
In Project "C", Properties, Post Build Events, use xcopy to copy the .exe and corresponding .pdb. Do this for both the "Debug" configuration and the "Release" configuration of Project C.
(For VB, this is under Compile tab, "Build Events..." button at lower right.)
In project A's Properties, find what its output path is. in this case, the path specified was bin\x86\Debug\. xcopy needs to be told this path, relative to project A inside the solution; this becomes $(SolutionDir)\A\bin\x86\Debug\. The resulting lines, to copy both the exe and its pdb for debugging:
xcopy /y "$(ProjectDir)$(OutDir)*" "$(SolutionDir)\A\bin\x86\Debug\"
This copies ALL files in "C"s output folder to "A"s output folder.
Before adding this line, examine "C"s output folder. Are there any files in it that should not be copied to A? If so, can they be deleted? (And will they STAY deleted, when you rebuild "C"?) If not, you will need to specify more carefully the source files, in xcopy line. Or use multiple xcopy lines, to specify the individual files.
Note the "A", which is the main project being copied to.
Repeat that line for "B".
As more variants of main project are created, add a line for them as well.
If one project specifies a different output path, then the lines need to be correspondingly changed.