can I configure jwrapper's xml so that a directory/file is included and put into the shared folder, not into the app folder ?
mydir/myfolder/foo
I would like to access it via
JWSystem.getAllAppVersionsSharedFolder()
Thank you
Peter
You can't have JWrapper copy files into the shared folder as it doesn't really fit in with how JWrapper works conceptually.
When you release a new version of your app the updated files will all be contained within the app folder (JWSystem.getAppFolder). From there you can save files that you want to remain consistent across versions to the all app versions shared folder (JWSystem.getAllAppVersionsSharedFolder).
However, managing the consistency of those files across versions and how they are updated is something that your app has to do since it will require context about what the files are and how they should be modified, updated etc.
If its just a case of overwriting files with the latest version then there's no real need to put them in the shared folder, you can just access the files bundled with your latest app version via the JWSystem.getAppFolder call.
Related
I need to bundle some data files (geoip data) with my meteor application. Simply putting the data files in my application directory doesn't appear to do anything - they're not copied to anywhere in .meteor/local/build when I run meteor.
How can I make meteor copy these files when it builds my application?
So, files are loaded on different environment is a specific order. Have a look here for details on what's loaded where and when.
https://guide.meteor.com/structure.html#load-order
Then you can decide where best to place the file depending on the use case.
What's the proper way to handle having multiple developers on a Meteor application? On each computer that I want to develop the app on I have to follow these steps to get it running after cloning from the repo:
Rename my-app/ to app/
Run meteor create my-app
Move all files from app/ into my-app/
Delete the auto generated my-app.*files
Re-add all packages (jquery, iron:router, etc...)
Note that I'm not including the .meteor/local directory in the repository.
I feel like I'm missing something obvious but it's not making itself apparent.
Push to the repo all files at the same level as the .meteor directory. Nothing to rename or meteor create. Yes, packages do need to be added, but the list of packages is specified in a file inside .meteor.
Just include the full .meteor/ directory in your repository. That way whenever the repo is cloned they will get the right version of meteor, a list of all the installed packages (which are downloaded at runtime) and any settings they need to run the app.
As far as I'm aware there is nothing in the .meteor/ directory that can't be shared across to different developers.
We are developing a framework including a number of EXEs based on Qt libraries. In order for one of the EXEs to correctly load SVG graphics we need to include an ImageFormats sub-directory in our application's main working directory with the qsvg.dll plugin. A problem arises because of the way that our framework's auto-update system works. It downloads an entirely new set of application, library and other files and saves them with their names plus a .new extension. It then renames the old files with a .old extension and completes the upgrade by removing all .new extensions from files names, restarting, and deleting files with a .old extension during application load. The problem is that for some reason, Qt doesn't require files in the ImageFormats directory to have .dll extension names. This means that during application load the qsvg.dll.old file gets loaded by the application and is therefore not deletable. The quickest way to fix this would seem to be if we could filter the names of ImageFormats plugins loaded by Qt, but I can't find a way to do this. Any ideas?
We're in the middle of changing from VSS to Subversion and we have a website project on our Subversion Repo. We've removed the Bin folder as it causes all kinds of chaotic tree conflicts since our development solution contains some Class Library projects the Website project depends on (set up as project references in our solution). We also have a couple of 3rd party library DLLs in the Website's Bin folder too.
The next phase of our project involves a designer modifying themes to our website. I'd like for him to be able to just open the Website project in VS 2005, modify the CSS files he needs to on his working copy, and test his files on his localhost. He'll need the most up-to-date DLL files for him to be able to do this.
Is there anyway to add the Bin folder DLLs to subversion, and configure TortoiseSVN or subversion so that we can commit our newest DLLs (project dependencies in developer's solution files) but ignore them on update (per client I guess)? It would also be handy to have our 3rd party website dependencies on Subversion too.
You should not put 3rd-party assemblies into the bin folder. In fact, you should assume that the bin folder will be emptied before each build. It is a place to put the output from a build, not a place to put inputs.
Put these binaries in to some other folder, maybe "3rdPartyAssemblies". Use a file reference to these files, and they'll be copied into the bin folder, as outputs.
Would it not be possible to structure it like this:
Trunk/
WebApp/
ClassLibrary1/
ClassLibrary2/
ClassLibrary3/
3rdPartyDlls/
build.bat
The web app is what pulls all the class libraries and the 3rd party dlls in to the WebApp's Bin folder (All of these will be referenced via relative links). You can then setup TortoiseSvn to call the build.bat file on update through client side hooks. You would also setup IIS on the designer's machine to point to the WebApp directory.
As other users have pointed out, you could use svn externals to pull in those enterprise wide class libraries.
What most everybody else has said regarding '3rdParty' is correct.
You may also consider svn:externals to pull in related directories including a '3rdParty' assemblies directory, or even output directories from builds that can be triggered by a check in to assure currency.
The approach we've taken is, rather than having the Libraries in the same solution, they have separate solutions and we (well, our Build server) compiles them and checks the compiled DLLs into sourcecontrol under "Dependencies" which is always mapped to C:\Dependencies on all developers machines. We then use file references to this folder from the website project.
Thi way you can give your designer the Website project along with a copy of C:\Dependencies and they'll be none-the-wiser =)
We don't sourcecontrol the bin-folder since it would be updated everytime you run a compile. Instead, we keep references to 3rd part libs in a separete folder that is under version control, that we have references to in our project.
With this setup and using "copy local = true", they are automatically added into bin upon compilation.
Secondly, we will only commit new binary files when we update the 3rd-part binaries.
This approach is also possible to do for your internal dlls, so that your designer can just compile his visual-studio-solution so taht any relevant dlls would be put into his bin-folder and hence, create a functional site locally on his machine.
I've just started using Subversion with ASP.NET web applications via the VisualSVN IDE plugin. There are a bunch of files which Visual Studio automatically generates so I don't want to version control these since they're not really part of the codebase and not required to build.
Does anyone have a definitive list of the main files that should be ignored when commiting to Subversion from an ASP.NET Web Application? and how would I go about ignoring these files. If possible I'd like to set it globally so that I don't have to keep doing the same thing for every ASP.NET Web Application that I write and create a new repository for.
Answers
A list of files to ignore as submitted in the answers below,
bin
obj
*.exe
*.pdb
*.suo
_ReSharper.*
*.user
General concensus seems to be that these should be ignored on a per project basis at the creation of the repository. They will then be ignored by all users using the repository.
Not really 'definitive', but I always ignore .suo and .user files and the bin/ and obj/ directories
Here's my ignore list from TortoiseSVN. VisualSVN requires TortoiseSVN and uses its settings.
bin obj *.exe *.pdb *.suo _ReSharper.* *.user
I haven't committed any unwanted (or not committed any wanted) files with this setting.
If you have any WCF service references then you only need to include the files Reference.cs and Reference.svcmap for each service reference.
The AnkhSVN plugin for Visual Studio has a list of files to ignore automatically and will only commits the files needed.
At least that's how I find it. It's taken me a few attempts at setting up the repository correctly but with AnkhSVN only commits a subset of he files that TortoiseSVn wants to commit. If ignores files recompiled on every Build for example.
Depending on your situation, you might want to keep the Web.config out of revision control as well. Different developers might require different configuration files for a website.
I'd recommend setting up a separate directory in your repository with a reference configuration file for the website and ignoring *.config on the actual project directory.
Additionally, to cover case sensitivity issues with "bin", I had to add [Bb]in to mine. So I have:
[Bb]in obj *.exe *.pdb *.suo _ReSharper.* *.user
Also, this link explains how to handle project specific excludes as well so that others get the same exclusion behavior only for the same project when they check it out:
http://svnbook.red-bean.com/en/1.1/ch07s02.html
I used the svn:ignore property on a particular directory to exclude a certain set of files that were copied into there (but I still wanted the directory itself in svn).
Use VisualSVN to do the initial "Add files to repository" and it automagically ignores the stuff you don't want-such as suo files and the bin/obj folders.