I want to replace the files whenever I deploy. Instead of replacing the existing ones, they just add up to the folder because each filenames are dynamically made.
I came across this "Remove additional files" default false and could be a solution to my problem.
However, while reading the description, the "destination" is kind of vague. Documentation here
When True instructs Web Deploy to delete files from the destination
that aren't in the source package
Is the "destination" pertains to the physical path?
Yes, the destination will be the value of the Physical Path setting.
I think the setting that will be of value to you is the File comparison method. It indicates the algorithm by which comparisons will be made to determine which files, if any, should be updated by the package.
This link is to a blog post in which the Timestamp and Checksum algorithms are discussed. I have included a portion of this post below.
Timestamp instead of checksum
In Octopus 3.0 we decided to make
Checksum the default (and only choice) for syncing files with
WebDeploy. Using checksum we would only deploy files which had
actually changed, without needing any special configuration. This
reduces the time and bandwidth required for subsequent deployments to
the same web app. This works really nicely for moderate sized
applications but, as we discovered, becomes prohibitively slow and
unreliable for large applications.
If you find yourself in this situation you can switch to using
Timestamp for file comparison instead of Checksum using Octopus Deploy
3.3.3 or newer.
Timestamp
If you have any existing Azure Web App steps you will need to update
them to use timestamp and create a new release. Any new Azure Web App
steps you create will use timestamp by default, but you can always
switch to checksum if that suits your needs better.
If you prefer checksum, we are planning to upgrade to
Microsoft.Web.Deployment.3.6.0 which has several bug fixes for
checksum comparisons.
Preserving timestamps
The downside with using timestamps for file
comparison is reliability - you can easily get false-positives -
that's why checksum is so attractive. If you are using NuGet packages
the timestamp of your files will be lost when they are unpacked
meaning every file appears to be newer and will be uploaded regardless
of whether it has changed - more detail. To work around this, consider
using zip packages - we have automated tests proving the timestamps
are preserved end-to-end through your deployments.
Related
I am writing a documentation for a project that involves multiple developers. We use Subversion (SVN) to work on our code base.
I wrote the first draft of the documentation document using HelpNDoc, which I like for the nice tree-view and easy of use; the problem is that there is a single file, so I don't know how to use SVN to allow other developers to contribute to the documentation and update it.
Do you know if it's possible? If not, can you advice a nice software, easy to use, with a tree-view of the documentation that can be used with SVN or makes it possible for multiple users to update it? We use Windows.
HelpNDoc projects are binary files based on the SQLite open source database engine. The advantage is that the whole documentation stored in a single file so it can easily be copied, moved, shared, backed-up...
However one drawback is that it has to be checked-in as binary content in any version control system including Subversion: diff and merge are not possible on those files.
One possible solution would be to use external documents in HelpNDoc's library: each user works on her own document (which can be a Word document, and HTML web-page...) and a master HelpNDoc project is created to include those documents at generation time. See "Include a file at generation time" in the following step by step guide: How to add an item to the library
Amount of files doesn't matter, real format (text/* or binary) - does. If SVN|any VCS can merge two HelpNDoc files with diverged history (just try it by hand), you'll be happy
I once used Helpinator for software documentation, it's pretty close to HelpnDoc but it's storage format is more suitable for version control.
Background
I am new to nDepend and wish to use it on a project that will be maintained with multiple developers in Subversion.
I am quite keen on keeping historic nDepend analysis results and notice that nDepend does that quite well by default by placing such results in the folder defined by $(NdProjectOutputDir) - usually a subfolder called NDependOut immediately beneath where the .ndproj file is located.
This means however that the generated nDepend XML and binary files are located along with my source code.
I have read the following articles by nDepend:
Trend Monitoring
Logging Trend Metrics
...and even tried a Google search "ndepend ndependout source control" which at the time of writing, the latter was not particularly useful for my questions below.
Questions
Should NDependOut be added to SCM? They strike me as essentially output artifacts as the result of the source code in the same way as compiling a project is and should not be added. But I am not sure that philosophy applies
If the NDependOut folder is added to source control for the benefit of other users, do I run the risk of conflict?
Should we instead nominate one person (or perhaps a build machine) to be the sole publisher of such reports?
I note at that in the root NDependOut folder there are two files:
NDependAnalysisResult_VIP_2015Jun11_18h33.ndar - binary
InfoWarnings.xml - text obviously
As you noticed you are quite free to decide. When you wrote:
This means however that the generated NDepend XML and binary files are located along with my source code.
...maybe it means you haven't seen the possibility to customize both...
historic analysis result + report storage root folder,
and trend metric storage root folders,
...both from NDepend Project Properties > Analysis, see screenshots below.
To answer your question in reverse order:
3) I'd say that if you choose to store this data in your SCM, it should be done by your Build Process automatically after a successful build process + NDepend analysis
2) No there is no risk of conflict on Historic analysis result + reports since they are stored in a hierarchy of folders named after the build date/time. Concerning trend metric yes there is a risk of conflict since the storage is made by one XML file per year.
1)
It is certainly worth sharing trend metrics with the team through SCM.
It is certainly worth sharing the baseline for diff analysis result as well through SCM. Typically the baseline for diff represents the last release in production code snapshot.
It is certainly worth sharing the most recent report generated by the build process (not necessarily through SCM, it should be available through an url).
Concerning all intermediate analysis result it is up to you, but if they are not used as baseline for diff, probably they will be useless.
What is the difference between using ext-all.js and ext-all-debug.js?
Does changing to ext-all.js from debug.js improve performance?
Can I assume that switching from debug to normal file will not have any other impacts on the application?
Also, can any one suggest what ext-base.js do?
Ext-all is basically the minified verion of the debug one. The gain is that it greatly reduces the files size so that clients have to download less. Ext-base are the core functions of ext. If you only use those you could just include that file instead of the huge complete set in ext-all.
On the ext site there used to be a custom js builder where you would pick just the functions you need and it would create a custom js for you with just those modules
Ext-all-debug is provided so that you can debug through the extjs code. It performs extactly the same operations that ext-all.js does. Using ext-all.js will improve performance since the size of the file is much smaller, hence clients can download and access them faster.
Same is the case with ext-base-debug and ext-base.js. These contain the operations on which ext-all.js depends on, for example Ajax operations. Interchanging these files will not have any effect on your application.
Use the ext-all-debug and ext-base-debug during development. Switch to ext-all.js and ext-base.js when in production.
THIS INFORMATION HAS CHANGED FOR THOSE USING ExtJS4.1.
After implementing and optimizing an application, I like many, was confused with which process was optimal for 'production implementation'.
This most current documentation for this turned out to be this document on Sencha:
http://docs.sencha.com/ext-js/4-1/#!/guide/getting_started
It was difficult to identify, but the key for me was step #3. Deploying Application.
For which these four steps are conducted:
cd to root
sencha create jsb - this creates a manifest of classes used.
- it can also be modified prior to build, in case it is needed.
sencha build - creates two files(all-classes.js, app-all.js)
- all-classes.js is non min for review.
- app-all.js is the production ready file
Setup for prod - these are the remaining includes needed in your production file:
ext-all.css //minified-css, concatenated and dusted is optimal.
ext/ext.js //non-debug
app-all.js //minified, concatenated, app + framework files (only classes used).
Hope this helps someone. : )
differences between "ext.js" and "ext-debug.js" are:
"ext-debug" is not compressed (or "minified").
"ext-debug" is not run through the Cmd optimizer.
These files otherwise contain exactly the same code. Further, both flavors download required classes from the "src" folder. In short, both of these files are intended to support debugging.
In order to improve the performance,To reduce the downloads to as few files as possible you can use Sencha Cmd. some thing like this
sencha fs minify -yui -from=ext-debug.js -to=ext.js
For Cmd topics ext 4.2.2 doc set is the more current and you can access the dec here
hope this may help you.
I have a program under version control that has gone through multiple releases. A situation came up today where someone had somehow managed to point to an old copy of the program and thus was encountering bugs that have since been fixed. I'd like to go back and just delete all the old copies of the program (keeping them around is a company policy that dates from before version control was common and should no longer be necessary) but I need a way of verifying that I can generate the exact same executable that is better than saying "The old one came out of this commit so this one should be the same."
My initial thought was to simply MD5 hash the executable, store the hash file in source control, and be done with it but I've come up against a problem which I can't even parse.
It seems that every time the executable is generated (method: Open Project. File > Make X.exe) it hashes differently. I've noticed that Visual Basic messes with files every time the project is opened in seemingly random ways but I didn't think that would make it into the executable, nor do I have any evidence that that is indeed what's happening. To try to guard against that I tried generating the executable multiple times within the same IDE session and checking the hashes but they continued to be different every time.
So that's:
Generate Executable
Generate MD5 Checksum: md5sum X.exe > X.md5
Verify MD5 for current executable: md5sum -c X.md5
Generate New Executable
Verify MD5 for new executable: md5sum -c X.md5
Fail verification because computed checksum doesn't match.
I'm not understanding something about either MD5 or the way VB 6 is generating the executable but I'm also not married to the idea of using MD5. If there is a better way to verify that two executables are indeed the same then I'm all ears.
Thanks in advance for your help!
That's going to be nearly impossible. Read on for why.
The compiler will win this game, every time...
Compiling the same project twice in a row, even without making any changes to the source code or project settings, will always produce different executable files.
One of the reasons for this is that the PE (Portable Executable) format that Windows uses for EXE files includes a timestamp indicating the date and time the EXE was built, which is updated by the VB6 compiler whenever you build the project. Besides the "main" timestamp for the EXE as a whole, each resource directory in the EXE (where icons, bitmaps, strings, etc. are stored in the EXE) also has a timestamp, which the compiler also updates when it builds a new EXE. In addition to this, EXE files also have a checksum field that the compiler recalculates based on the EXE's raw binary content. Since the timestamps are updated to the current date/time, the checksum for the EXE will also change each time a project is recompiled.
But, but...I found this really cool EXE editing tool that can undo this compiler trickery!
There are EXE editing tools, such as PE Explorer, that claim to be able to adjust all the timestamps in an EXE file to a fixed time. At first glance you might think you could just set the timestamps in two copies of the EXE to the same date, and end up with equivalent files (assuming they were built from the same source code), but things are more complicated than that: the compiler is free to write out the resources (strings, icons, file version information, etc.) in a different order each time you compile the code, and you can't really prevent this from happening. Resources are stored as independent "chunks" of data that can be rearranged in the resulting EXE without affecting the run-time behavior of the program.
If that wasn't enough, the compiler might be building up the EXE file in an area of uninitialized memory, so certain parts of the EXE might contain bits and pieces of whatever was in memory at the time the compiler was running, creating even more differences.
As for MD5...
You are not misunderstanding MD5 hashing: MD5 will always produce the same hash given the same input. The problem here is that the input in this case (the EXE files) keep changing.
Conclusion: Source control is your friend
As for solving your current dilemma, I'll leave you with this: associating a particular EXE with a specific version of the source code is a more a matter of policy, which has to be enforced somehow, than anything else. Trying to figure out what EXE came from what version without any context is just not going to be reliable. You need to track this with the help of other tools. For example, ensuring that each build produces a different version number for your EXE's, and that that version can be easily paired with a specific revision/branch/tag/whatever in your version control system. To that end, a "free-for-all" situation where some developers use source control and others use "that copy of the source code from 1997 that I'm keeping in my network folder because it's my code and source control is for sissies anyway" won't help make this any easier. I would get everyone drinking the source control Kool-Aid and adhering to a standard policy for creating builds right away.
Whenever we build projects, our build server (we use Hudson) ensures that the compiled EXE version is updated to include the current build number (we use the Version Number Plugin and a custom build script to do this), and when we release a build, we create a tag in Subversion using the version number as the tag name. The build server archives release builds, so we can always get the specific EXE (and setup program) that was given to a customer. For internal testing, we can choose to pull an archived EXE from the build server, or just tell the build server to rebuild the EXE from the tag we created in Subversion.
We also never, ever, ever release any binaries to QA or to customers from any machine other than the build server. This prevents "works on my machine" bugs, and ensures that we are always compiling from a "known" copy of the source code (it only pulls and builds code that is in our Subversion repository), and that we can always associate a given binary with the exact version of the code that it was created from.
I know it has been a while, but since there is VB De-compiler app, you may consider bulk-decompiling vb6 apps, and then feeding decompilation results to an AI/statistical anomaly detection on the various code bases. Given the problem you face doesn't have an exact solution, it is unlikely the results will be 100% accurate, but as you feed more data, the detection should become more and more accurate
Whenever we recompile an exe or a DLL, its binary image is different even if the source code is the same, due to various timestamps and checksums in the image.
But, our quality system implies that each time a new DLL is published, related validation tests must be performed again (often manually, and it takes a significant amount of time.)
So, our goal is to avoid releasing DLLs that have not actually changed. I.e: having an automatic procedure (script, tool, whatever...) that detect different Dlls based only on meaningful information they contain (code and data), ignoring timestamps and checksum.
Is there a good way to achieve this ?
Base it off the version information, and only update the version information when you actually make changes.
Have your build tool build the DLL twice. Whatever differences exist between the two are guaranteed to be the result of timestamps or checksums. Now you can use that information to compare to your next build.
If you have an automated build system that syncs source before starting a build, only proceed with building and publishing if there any actual changes in source control. You should be able to detect this easily from the output of your source control client.
We have the same problem with our build system. Unfortunately it is not trivial to detect if there are any material code changes since we have numerous static libraries, so a change to one may result in a dll/exe changing. Changes to a file directly used by the dll/exe may just be fixing a bad comment, not changing the resulting object code.
I've looked previously for a tool to do what you desired and I did not see one. My thought was to compare the two files manually and skip the non meaningful differences in the two versions. The Portable File Format is well documented, so I don't expect this to be terribly difficult. Our requirements additional require that we ignore the version stamped into the dll/exe since we uniquely stamp all our files, and also to ignore the signature as we sign all our executables.
I've yet to find time to do any of this, but I'd be interested in collaborating with you if you proceed with implementing a solution. If you do find a tool that does this, please do let us know.