Admittedly - I have minimal knowledge of what's going on here. However all I want to do is get this environment up and running so I can start to mess around with developing a single page web app in the C9 IDE. Any help, literally any, will be incredibly appreciated.
Html and CSS files also known as "static" files are usually kept in a folder called public or client. It differs from language to language and framework to framework and also depends on personal preference or team preference. There are no real right places for you to place your static files yet best practices can be found if you google python folder structures. As long as your files can see your other files when you point to them you're set.
Related
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.
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
This question is kinda similar to this one, but not exactly. I have a game engine in C#, and I'm working with some people who want to use my engine. Originally I designed the engine so that all the assets are external - non programmers can create art, music, xml settings, etc. and that anyone could modify an existing game, and share them amongst each other. Basically the whole thing including the engine itself is open source.
The group I'm working with (one of only two projects using my engine currently) wants to close their assets so they can't be modified. Although it's against my principle, I don't want to turn them away, both because I've already been working with them a while and because the market is very small (both for engines like mine, and for users of those engines).
The Actual Question
Is there a way, maybe some available software, that can take an exe and a bunch of other arbitrary files, and smash them into a single exe, that isn't just an archive? I would like the final exe to behave like it runs the first exe with some command line parameters that refer to the bundled files. For example, running bundle.exe would be just like running original.exe --project_path=/project but the project files are inside the bundle, and cannot be retrieved from it.
My original exe is written in C#. I doubt that matters.
You could pack these files as embedded resources.
We are working on an ASP.NET MVC 3 project and taking advantage of Razor syntax to resolve paths and what not.
We are also employing a UI design team who is responsible for maintaining the design of our pages through the use of CSS and modifying the HTML in the cshtml pages.
The problem is, they work exclusively on Mac laptops without access to a web server or a .NET IDE.
Initially, they were just providing us a straight .html file along with a .css file and we were manually merging in their work into our ASP.NET solution (e.g., replacing paths with Razor markup, etc), but as the project grows and we become more involved, we are looking for a solution that will save us from these manual merges.
I was thinking I could create some kind include script that would rewrite the paths depending on whether the UI designers were editing the file, or the .NET devs, but this seems archaic.
Anyone out there been in this situation before?
Razor is a templating language, and a pretty small one at that. Could your UI team familiarize themselves with enough of it to deal with their own links? I'm sure they are familar with your view hierarchy since they are going to be building it, so it shouldn't be much of a leap to explain how controller and action paths work.
Razor files can be edited outside of a .NET IDE just fine...any old text editor will work since it's not like there's anything you have to compile. You could provide them with an instance that they could copy their files to via a shared drive (cifs) to test them on. I don't see any reason for your UI team to be required to use Visual Studio.
You could just rename your .cshtml file to .aspx and reload it in VS and design away. when you are done, rename it to .cshtml
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.