I have all the forms in one folder and all the code modules in an other folder in VB6. How do I create a better folder structure for the source files?
For example if I have twenty forms and twenty code modules, how can I create subfolders Main, Sales, and Employees and put the source files under those subfolders?
You should investigate whether some of your files could reside in a ActiveX DLL instead of the main EXE project. As Konrad pointed out the VB6 IDE project explorer doesn't support folders. Large VB6 projects, like my own, organize the classes into a hierarchy of ActiveX DLLs. For example Utility DLL which has commonly used routines used across the company's applications (file handling, etc). Business Object DLL which has the specific classes used by your applications. Report DLL has the classes that handles reports for that applications. And so on.
The gotcha is that you have to worry about compatibility issues between versions.
You can (and should) create subfolders in the file system to organize your files. However, this hierarchy will not be mirrored by the VB6 project explorer, which basically provides a flat hierarchy.
well if you're talking about adding a new folder from vb6 project explorer view,
i'm not sure that you can do so.
but if you want to sort it you can apply some naming convention, i.e. module1_xxx, module1_yyy.
Related
My ASP.Net Core MVC project consists of 3 website projects, plus associated unit test projects, all collected in a single solution. Each of the website projects relies on common stuff, such as JavaScript libraries (under wwwroot/js/...) and views (under views/...). Is there some feature that lets me package up these files (none of which, as far as I know, can live in a NetStandard library project) and "install" them in all of my website projects so I only need to maintain them in a single place?
A razor class library (RCL) almost does what I want to do, but I want to be able to reference my JavaScript library from views in all three website projects. I also want the bundler/minimizer to be able to find my common JavaScript and CSS files. As far as I can tell, RCL only allows the Razor Pages in the RCL to access the static content (things like my JavaScript and CSS files) in the RCL.
EDIT:
After more thought, I've come to the conclusion that what I'm asking for simply can't be done "out of the box". In order to work correctly, the debugger and the bundler/minimizer need to find js and css files in the project's directory tree. What I'm asking for is a way to have something like a "reference project" that contains these "shared" files. I'm thinking that it's time for the "science project" approach: I'll create a reference project that contains the shared files, and run some code (at build time? via MSBuild? via unit test code?) that updates the files in the project from the reference project if they don't match.
FWIW, here's what I wound up doing:
In my 3 website projects, I have common files in several places:
Views/Shared
wwwroot/js/MyJsLibrary
wwwroot/css/MyCssLibrary
I created a "reference" project that contains copies of the common files in these folders. Then I created a unit test that simply verifies that the files in the "reference" project exist and are identical to files in each of the 3 websites.
No automated magic to keep the folders in sync. If someone changes one of the common files then the unit tests will fail until someone copies the updated file to the website projects and to the "reference" project.
I'm using Visual Studio to code a C++ program, with its source repository managed by SVN. I'm trying to have the solution compliable on multiple computers. The problem is, the libraries and include directories differ on both computers.
For instance, on one, the libraries are in (for instance) e:\devlib\boost_46_1\libs\regex\build, E:\devlib\SDL-1.2.14\lib etc and on the other computer in c:\programming\lib\boost_46_1\libs\regex\build and c:\programming\SDL-1.2.14\lib
Likewise for includes - which have the added layer of complication as to needing to retain the folders in the #includes in the actual source code (such as #include )
How do I structure my folders/source/vs solution/computer to make the solutions be able to compile on any of my computers without me having to separately list the library folders and maintain different project/solution folders for each?
I do understand one potentially valid solution to be include the libraries in the folder structure of the source, so that all the library folders can be, for instance "../libs" and "../inc" or something. However, given the sheer size of (for instance) boost, this solution is undesirable - especially with source control.
Place any third party libraries into a folder in your solution, place under source control and reference from this solution rooted folder.
Don't worry about the size; since these won't change that often, you will retrieve them infrequently.
I need to rebrand my application, that means create another application resource file with different strings, slash screen and icons.
My application is also localized for a second language, i have another resource file with all application string which is translated, that creates me additional, satellite dll.
I need to build 4 setup project 2 for each language and 2 for each brand name.
What will the elegant solution for this? Is there any way to create additional application resource file same way I did with language translation and how I include a satellite (resource in a second language dll) in my setup project and not including resources in the original, neutral language.
Thank you.
I assume that those branding resources are not in setup project, but in main project, and that main project is C++.
In C++ you can have several .rc files in a project. This is most likely true for C# resources too. Move all branding material to second resource file. Create another project, shallow in nature, that references all files (including .rc) from original, but uses its own versions of branding files. Apart from strings, icons, and images maybe you will have some dialogs copied and branded as well. Make sure they all have resource identifiers in sync.
Creating another project can be done by just copying original project and fiddling with paths in text editor. Just make sure you change the project GUID, so that two project can coexist in the same solution.
Maybe that's silly, but I'm confused again when trying to find appropriate names for my projects.
I have a solution with two projects. First project is a library, which will be used by other libraries in the future, for creating plugins for my app. Second project is a exe, which uses first project to create GUI and do some stuff, eg. load plugins.
In similar situation, when one project is a dll and second is an exe, how do you choose names for each project?
Lets say, that I would like to peek a name GraphDemonstration. The exe should be GraphDemonstrationGUI and dll - GraphDemonstration? But exe is not just a GUI. So maybe GraphDemonstration for exe and GraphDemonstrationLib for dll?
I have had similar situation in the past. Maybe there is some kind of naming convention? I don't even know if my "problem" is related to VS only.
GraphDemonstration for your EXE is fine because it describes the purpose of the EXE. However, you said the library will be used by other projects later so the "GraphDemonstration" part of GraphDemonstrationLibrary may not be the best choice. Perhaps GraphLibrary, or GraphHelper, or maybe more specific depending on what is actually included in the library. For example, if the library handles instantiating an Excel object to generate a graph you could call it ExcelGraphHelper.dll.
If this is library of main class CSomeClass I name project SomeClassLibrary.
For projects smillary but non from main object.
I have been using the Codesmith framework NetTiers to generate a DAL etc., into a folder called, say, 'NetTiers', outside my main project's folder, and referencing the DLLs within that folder from my main project.
I've started using the Plinqo framework, and want to use the generated files from that framework within the same project as the one I'm using with NetTiers. (The reason I'm using both frameworks is that I want to get/learn the newer LINQ goodness from Plinqo, yet also have the familiar NetTiers code DAL, BLL syntax available, for compatibility.)
My question is: what's the best Visual Studio solution and file structure to use when using Codesmith templates like these? Should the frameworks' generated code be contained outside the main project and added as projects to the overall solution? Or should each template's generated code have its own solution? Should the generated files be within the main project's file structure?
I've tried combinations of each of these, and they each have their pros and cons. I'd like to know if there's a tried and tested pattern.
When it comes to .netTiers, I always compile the generated solution and add the assemblies as references to my project. This makes it much easier to upgrade/diff and regen.
However, there are going to be some cases where you would want to add your custom logic so keep this in mind.
Thanks
-Blake Niemyjski
I tend to just keep the .csp and the generated folder outside of my main app's folder. When adding a reference Visual Studio copies in the .DLLs from the built generated code. All of the generated projects sit under a main folder such as D:\CodeSmith Projects\
If you want to version control the .csp file it might be beneficial to move it in with the rest of your version controlled app files to tie it all together.
We put the generated projects inside our solution. In fact on my current project I generated the nettiers files to the location that I wanted the files to be, and Started adding my own project files to that...But we have always kept the files in the solution, that way if i need to add something to the code in the concrete classes I can do it without having to open a whole new project.
We have tried both scenarios. We settled for including the assemblies in a dependencies folder, which was shared by multiple projects.
We had problems with TFS when the projects were included in the solution. the downside, is that you can't so easily step into the .NetTiers generated code when debugging, though after a while you get used to this, and accept that whatever is in .NetTiers stays within .NetTiers!