I've been writing bots that run on a platform I do not have control over. Essentially, I can upload a single file, and it only has access to basic JS and the site runtime. I chose to actually develop in TypeScript and transpile, to make things easier (imo). Since the initial bot was written for an individual, I've been asked for a few other customized variants. I do not mind this as there is very little in the bots that need to be changed per person. I have been hardlinking the common files between the projects, so as to not have to update in multiple places. This is, without a doubt, a bad solution. I am developing this in Visual Studio 2015, although I also have Visual Studio Code available, if anyone knows of a better build method. I am not very familiar with either, however. I would prefer being able to keep the common files in one project, and import them as dependencies. Maybe I missed something obvious, but attempting the same as I would do for C# did not seem to work.
From the way you are describing things, it sounds like you need to use some sort of custom build.
I would keep each of your bots in the same project and make sure that they share code appropriately, and then after tsc transpiles your files, concatenate them for each bot. So, each bot will get the files that it needs all stuffed into a single, gargantuan file.
You will need to do some trickiness, like parsing import/require statements, or include some kind of directives in each file that describes what other files are needed.
This doesn't sound too tricky to do and is the approach that I would take given the problem description you have provided.
As it turns out, you can declare a tsconfig.json file, and in there, specify things like included directories and specific files. This wound up being exactly what I needed, and was remarkably easy to set up. I've been updated the apps/bots for a while now using this system, and all the common files are effortlessly "shared" between then, with only recompilation necessary.
Related
I have created three different solutions for three different clients, but those solutions are for an app that have the same features, classes, methods, resolution, except for the images, XML resource files, and a web service reference, that are specific for each one.
I would like to have just one solution for all those apps, that I could open in VS2010 IDE for edition, without errors. So, when I need to build or publish an specific app, I just set the client which one I need to, and go ahead to building or publishing.
It is important to consider that XML file names will be the same, as classes and images names too. The difference will be the content, but the name will always be the same.
My intention is to reduce my effort to maintain many solutions, having just one solution to work with.
In my company, we will have more than those three clients soon, so I am worried about how to maintain that. The best way will be have just one solution and when I need to generate a new app for a new client, I have just to change/include a few things (like some resources and images) and compile to a new client folder.
Is it possible? If so how?
One option would be to have a master solution which had the following
A "Template" project that contained your actual application and all of the shared code
Projects for all of your clients
In the projects for your clients, you could have links to the files in your files that come from your shared project. Then, in each of those projects, you could add the files that are only specific to them.
With this kind of structure, whenever you made a change to your Template project, all of the client projects would be updated as well because they just have pointers back to the Template project.
A good reference for this kind of setup would be the Json.Net Code Base. There he has a solution and project for all of the different configurations, but they all share the same files.
In terms of ensuring that the xml files are named properly, you might just want to put some checks into your main application to ensure that it has all of the files needed or potentially add a check into your build process.
There are many ways you could look to tackle this.
My favorite would be to run some sort of pre-build step - probably outside of Visual Studio - which simply replaces the files with the correct ones before you do a build. This would be easy to automate and easy to scale.
If you are going to be building for many more than three customers, then I think you should look to switch from Visual Studio building to some other automated build system - e.g. MSBuild from the command line or from something like TeamCity or CruiseControl. You'll find it much easier to scale if your build is automated (and robust)
If you don't like the file idea, then there are plenty of other things you could try:
You could try doing a similar step to above, but could do it inside VS using a pre-Build step.
You could use Conditional nodes within the .csproj file to switch files via a project configuration
You could look to shift the client-specific resources into another assembly - and then use GetResourceStream (or similar) at runtime to extract the resources.
But none of these feel as nice to me!
I have an existing MFC product and am planning on supporting a couple of other national languages thru the use of resource-only DLLs. I've read a number of articles and tutorials on how to go about this, but admit that I don't have a lot of in-depth knowledge of Windows resources (mostly just use VS 2008's graphical interface).
The major area that I am trying to understand is that it seems like all of the resource source files (i.e., resource.rc) for these DLLs -- and the main program -- should be sharing the same copy of resource.h. After all, all those IDD_xxx values have to be consistent, and it seems like making updates to the resources would be even more complicated by having to keep multiple resource.h files in sync!
So am I correct on this, and does anyone have any tips for how to best implement this? Should I modify resource.rc in the DLL projects to point to the "master" resource.h in the main program directory?
Yes, use the same resource.h file for sure.
One way is to just copy the resources you need to be translated into the the new resource project--stuff like menus, strings, dialogs. Bitmaps and icons probably don't need to be translated unless you put some text on them that is language specific. If you know your localse, at program startup you can call AfxSetResourceHandle() with the resource DLL you manually load.
Another way to approach the problem if you have a multitude of DLLs and EXEs is to use binary resource editing tools. What they do is create token files from your resources. Your translators edit the token file with the binary editing tool. When all is done, you run a tool to apply the translation to the binaries. Basically, you don't distribute resource DLLs, but distribute different versions of your DLLs for each language. The tools are smart enough so that if you make a change like add a string or dialog, it will get picked up and your translator can see that he needs to translate something new. The previously translated work will be saved in the token files. This is how we do it at my shop. We used to use Microsoft's Localization Resource toolkit. I don't know if we still use it or not since it is somebody else's responsibility now.
I found the MSDN article ID 198846 a good starting point for sharing of resources via a dll, though it does need updating for newer versions of visual studio, it was quite easy to follow and understand.
http://support.microsoft.com/kb/198846
In most .NET project I can use folder to organise the code files. In C++, I can't, but filters end up playing the same role. However, in F# with Visual Studio 2010, I can't. Every code file is shown directly in the project dir. Why is this feature not available?
And what is the optimal strategy for organizing a project with a lot of files?
Actually, you can add folders to F# projects but it's not supported directly through Visual Studio (you have to edit the project file yourself): http://fsprojectextender.codeplex.com/ (edit: old link was broken, updated to F# Project Extender home page which has links to the original blog posts which were moved) (which I found in this answer).
I do this myself, but it is cumbersome and you end up avoiding it until keeping sanity really demands it. I think the feature simply slipped, or perhaps there wasn't as much a culture for folder organization with the F# designers in the first place. You can see in the F# source code that they favor huge source files with no directories, with separate projects as an organization boundary.
I imagine the F# project template could be modified to support this, and it is certainly something I'd like to see happen. At the same time the linear compilation order F# enforces causes your code to be somewhat self-organized, and so folder grouping plays a less significant role.
Manually editing the .fsproj file as described in Stephen's answer is one option (and I used it when I wanted to organize one larger project).
However, you have to be a bit careful and I think you cannot add new files to the folders (creating a file by hand and then adding an existing file works). However, if you like to keep things organized (like I do), then it should work for you.
Additionally, there is also a tool called F# Project Extender that should make things a bit easier for you . I have not tried it yet, but it looks like it supports adding folders (and perhaps other useful things). See for example this blog post by the project author.
Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
Put shared codes in separate Solution/Project as Class Library,
In post build event of shared projects copy dll's to a specific directory,
Add shared dll's from this directory to other projects/solutions
By doing this each time you build your consumer projects, they will use latest dll's automatically.
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.
I can't seem to figure out the most efficient way to do this.
For example, I have some js files that are needed in both projects(within the same solution), how do I include them without duplicating the actual physical files, which I would rather not do? Same goes for images and css files.
I would also like to know what's the best way to generalize this for including the js resources in other solutions/projects.
VS really seems to be lacking an easy intuitive solution in this retrospect.
Any ideas?
Why does it matter which project they are in? All you really care about is where they get deployed on your web site, and what the path to them from the root of your site is, right? So just pick a place to put them and have and code that refers to them use that path.