Let's say I have a folder 'content' that (for some reason) may or may not be present in the source folder tree for a Web Deploy sync operation.
With what skip setting(s) can I have Web Deploy sync the contents of this folder (regardless of whether it exists; I can use another skip setting to control which files are synced) without also deleting the folder in the snyc target when it doesn't exist in the sync source?
[Note – the line breaks in the example commands are purely cosmetic.]
With this command, Web Deploy will attempt to delete the 'content' folder in the sync target (and fail if there are files in it):
msdeploy.exe
-verb:sync
-source:dirPath=%source%
-dest:dirPath=%target%
-skip:skipaction=Delete,objectname=filePath,absolutepath=\\content
With this command, (it appears that) Web deploy will skip deleting the 'content' folder in the sync target but it will also fail to sync any files within that folder (which is eminently reasonable actually):
msdeploy.exe
-verb:sync
-source:dirPath=%source%
-dest:dirPath=%target%
-skip:skipaction=Delete,objectname=dirPath,absolutepath=\\content
It's perfectly acceptable if there is in-fact no way to do this! (But I'd like some details or references about why that would be.)
Some possible solutions:
Have a look at the -enableRule:DoNotDeleteRule switch (see rule descriptions).
You may need to include both of those skip params, per this blog post:
...delete rules on a child are only processed if the parent is not
being deleted. So if you skip a file but it’s containing directory
doesn’t exist on the source, the directory (and thus the file) will be
deleted anyway.
Also, remember the absolutePath param takes regex so some chars (like .) should be escaped.
This doesn't seem possible. If a skip delete rule prevents a folder from being deleted, then none of the child files in that folder will be deleted either, and thus the child files won't be synced (completely).
Thinking about this more, especially in light of jkoreska's answer, I think the solution I adopted isn't terrible. Basically the problem is that the source and target root folders may contain some subset of a set of folders, say for example the full set is bin, content, and templates.
The reason why I want to sync the contents of a folder that might not exist in the source (or target), is that I'd like to use the same Web Deploy command(s) for any number of instances of sources and targets.
My solution was to simply guarantee that the source instances always contained the full set of folders, and thus all of the targets would too – after at least one execution of the Web Deploy command(s).
Related
Using JXBrowser 6.14...
I'm using a different context for every Browser instances, that means I'm creating a temp folder for every Browser instance that I have, I've decided to remove this temp context folders when the Java application shutdown the problem is somewhere this context folders still being used for JXBrowser so I'm not able to delete them. I've also used deleteOnExit() but I'm still facing some problems with some files.
So, I'm wondering is there a way to clean up all those context files/folders? probably when the Browser disposed...?
Thanks in advance.
Before you start deleting this folder, make sure that you dispose all Browser instances with BrowserContext configured to use this folder. If you have at least one running Browser instance that use the folder, you won't be able to delete it.
Also, make sure that you first delete all files inside the folder, and then remove the folder (empty) itself. As far as I know Java doesn't provide API that allows deleting folder with files inside. At least 1.6. First you need to delete each file.
I know the Meteor file structure is a bit ambiguous, but at this point some conventions has formed and I was wondering where people usually put the code that runs on both server and client. I would like to keep it in a separate folder/file to make the project folder more manageable. I have a client folder for client-side code, a server folder for server-side, and a public folder for public files. But I'm unsure what the conventions say about the shared code that runs on both the client and the server, like declaring collections, etc.
Thanks!
From the docs,
All JavaScript files outside special directories are loaded on both the client and the server. That's the place for model definitions and other functions. Meteor provides the variables Meteor.isClient and Meteor.isServer so that your code can alter its behavior depending on whether it's running on the client or the server.
Also from the section on File Load Order,
There are several load ordering rules. They are applied sequentially to all applicable files in the application, in the priority given below:
HTML template files are always loaded before everything else
Files beginning with main. are loaded last
Files inside any lib/ directory are loaded next
Files with deeper paths are loaded next
Files are then loaded in alphabetical order of the entire path
This suggests that the best practice would be to place the files in the lib/ directory.
After pre-compiled a ASP.NET web site, I got many files with the names like
App_Web_accountbalance.aspx.dfa151d5.dll
Do you know the rule for the random chars (in bold) above?
Can we fix the random chars?
The reason to fix it is that if we modify AccountBalance.aspx file later and re-compile the web site, can we just replace App_Web_accountbalance.aspx.dfa151d5.dll.
Thank you.
The characters are not random, but more in line with hashing. The purpose is to make the file name unique in the bin folder. Although not advisable, you can replace just certain files to update your website. If you modify AccountBalance.aspx and recompile, you need to replace App_Web_accountbalance.aspx.dfa151d5.dll, accountbalance.aspx.dfa151d5.compiled, and other assemblies and files that your aspx file depends.
I derived the answer from my experience. I was not looking for the file naming rule, but a way to deploy just the assembly of a changed page, same reason as the original post.
The setup:
A web application, deployed non-updateable (updatable=”false” in PrecompileApp.config), pre-compiled assemblies with no fixed names
What I did:
Make the change to the page (say, a.aspx) in development (Visual Studio 2010)
Publish the site with fixed naming to local drive (Build > Publish Web Site, check the box: Use fixed naming and single page assemblies)
Go to the bin folder of the local publish site and look for a.aspx.xxx.compiled
Open the file with Notepad and note any dependency (say, b.aspx, c.master)
Copy all the affected assemblies and the .compiled files to the bin folder in production server. In this example, they are:
a.aspx.xxx.compiled
b.aspx.xxx.compiled
c.master.xxx.compiled
App_Web_a.aspx.xxx.dll
App_Web_b.aspx.xxx.dll
App_Web_c.master.xxx.dll
If you want to know my story, the change was due to a change in a factor in a calculation. The customer knew of the change much earlier, but did not let us know until it became urgent. A proper deployment would involve other parties and much coordination, and would be too late. Plus, I only had the source code of two versions back, and requesting the latest would take time. So, a hot fix on just that calculation change was required as a temporary measure.
1) you can generate single assembly per web application if you want. So when you make a change in web application, you only need to deploy just one dll.
for this, you can check option "Use fixed naming and single page assemblies"
2) Reference from MSDN Article: "The assembly names are generated automatically by the compiler and it is therefore not obvious which assemblies map to which source files. The compiler also creates new names each time it runs, so that the names of assemblies might not be the same after each compilation. In addition, if source files have changed, the compiler might batch up source files differently, meaning that the resulting assemblies do not necessarily represent the same source files. If you are maintaining a deployed Web site and want to update only the assemblies for recent changes, the output from batch compilation can make that job more complicated.
To help you in this situation, aspnet_compiler.exe supports an option specifically designed for packaging and release management: the -fixednames option. This option enables you to create compiler output that has two benefits. The first is that the assemblies produced by the compiler have the same names each time you compile. The second is that the assemblies are based on the same input files each time."
http://msdn.microsoft.com/en-us/library/aa479044.aspx
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.
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.