We recently implemented mandatory reviews (Helix Swarm) for the files that are checked into our source control (Helix Perforce). For now this also applies to files that are tool generated, InstallShield .ism files in particular. Since they are text files, a classic diff can be reviewed. The quality of such a review of course is poor, because the files are not intended to be human-readable. An alternative is to open the files in the InstallShield editor, but only few people in my team have the needed license which prooves to be a significant bottleneck in review speed.
Because of the aforementioned problems we are discussing to abolish reviews for InstallShield alltogether. I'd like to know if there is a feasable way to review InstallShield files, so that two people can have a look at changes in the installation routine.
For now we have decided to just do simple plausibility checks. Compare what is described in the pull request with what information that can be easily grasped from the presented diff of the XML file.
Example:
Descripion: Add/Update Library xy
Check if added/changed/deleted lines are containing the library name and possibly version.
If lines of seemingly irrelevant files changed, it's a reason to report a possible defect.
This may not be a perfect quality control of what the setup will finally do, but at least we can catch obvious mistakes early on, without the need for further tooling.
You can add 'MsiDiff.exe' as diff application by extension in Perforce to review InstallShield ism files.
MsiDiff.exe can be found in [IS-INSTALLDIR]\System.
Here is how you can add it in Perforce:
Perforce diff application by extension
Related
we actually build an InstallShield project for our application with the functionality to include files dynamic into a component. All files will be taken which are in a specific place.
Because of problems, which are not part of this question, we want to change this to components where we add files explicit to custom separated components.
The question is, is there a best practice for this? We have the small fear that we easily can forget to add files to the component we new created. These can be dll files, .config files, pdfs or just xml.
(We build the installer every night using TFS.)
We found a solution for the problem.
What we wanted to solve:
During the build we want to be informed if files got removed
During the build we want to be informed if new files are missing
we solved this by two more or less easy things.
1. Information if a file is removed
This is easy sone, we have all files added explicitly, each single file is an own component now, if one file is missing the whole project does not build with the exact error message.
2. Information for missing files
For this we wrote a small tool which runs by a prebuild event of the installshield project.
There it opens the *.ism file as an xml file and searches for the "Files" table.
Than it takes all files from the drop folder and looks if all files are in there.
If there are files missing but we don't expect them, like pdb files or test dlls, we have an additional text file we just called "IgnoreList".
The tool skips these files by the check.
Now we are on a very good state to get informed directly on the next morning if the project was able to build or not, and if not what happened, so we can be sure that in the final target application are files are there :-)
Update: It appears that VS doesn't have the hooks needed to do what is needed in my use case. However there are a couple of options that could work for other people and as such I'm marking the question as answered but I would love to find a solution that works for me.
We have encrypted files that are routinely kept in encrypted form within source control (TFS). When I want to compare versions I use Beyond Compare and have added the encryption/decryption tool as filtering on the read/write process to allow plain text viewing and editing.
However if I just want to open the file for reading/editing it's a bit tedious using a dummy comparison just to view/edit the file.
As such as I wondering if there is a configuration setting or way in Visual Studio that would allow me to insert a filter on the read/write so that it could display/edit/save files that would otherwise be unreadable.
Edit:
*NB: The encryption aspect is just single use case *, I'm actually looking for a generic answer that doesn't require writing an editor to replace the editors within VS that already exist such as the MS supplied XML editor or the custom third party ones.
I have both custom and non custom files that are encrypted. Each file type already has an editor. We have no access to the source for any of these editors. The problem is that the file is encrypted in TFS, and all I need is the filtering on the read and write for all files regardless of editor.
I want to use all the existing features of the installed editors without change. Only the reading and writing need to be customised.
Here's a potentially hacky way to achieve what you are trying to do, if there is no other easy option.
TFS stores data in a SQL database. Therefore you can theoretically modify the read/edit command that is used to extract the data from TFS and send it to the editor/viewer. This might involve modifying a stored procedure, or putting a trigger in place to modify the data before it is presented to the editor.
You would need to run a Profiler Trace on the TFS database when you click on edit/view or browse to the node in the source control tree. This will help you to figure out what data TFS is accessing and what functions/stored procs/tables etc it used to extract said data.
The same in reverse; you'd need to modify the 'writing' of the data to use your custom tool before putting it in the DB.
SQL has the ability to call CLR code, so you could use your tool if it's written in .NET.
The easiest way would be to download the 2012 SDK, Microsoft already provide a nice walkthrough on how to implement your custom editor HERE.
The process is:
Install the SDK
Fire up VS2012; Select New Project -> Other Proj Types -> Visual Studio Package
Visual C#, company name, etc...
Tick the "Custom Editor" tickbox
Fill in the rest of the details
So now you're presented with all the source of a vanilla text editor, and the part you want to hook in to is the IPersistFileFormat::Load() and IPersistFileFormat::Save() functions found under EditorPane.cs and put your encryption/decryption routines in there, thus you'll be left with a text editor with a custom encrypted file format.
This may not do what you need, since you need to call third party exe. However this answer may be useful for others that have access to source code (or a dll or library).
You could write a file system filter that encrypts/ decrypts the data to and from disk. Note that the driver sits at the OS level, and is outside of Visual Studio.
From the MSDN article File Systems and File System Filter Drivers:
A file system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. Examples of File Systems and File System Filter Drivers include anti-virus filters, backup agents, and encryption products.
See this Code Project article for a tutorial: File System Filter Driver Tutorial. The article does not show how to do encryption/ decryption, but shows how to get a simple driver up and running.
There are extensions that will capture events to the current window save for example and what turns out to be document load. ** This is not a custom editor **
check out the following two links:
http://msdn.microsoft.com/en-us/library/dd885244.aspx
and a fairly complete open source addin that works with files when saved (regardless of type)
https://bitbucket.org/s_cadwallader/codemaid/src/7cf1bf6108801f48b85e30d85e1646fbc73ba889/CodeMaid/Integration/Events/RunningDocumentTableEventListener.cs?at=default
which hooks the RDT table to extend the current environment. You would need to adjust from here of course but this should get you going in the right direction.
The default patch file viewer is messy (ie. no side by side diff view etc). I tried setting the path of beyondCompare exe in "Settings->Unified Diff Viewer->custom", but beyond compare also behaves same as default diff tool.
Is there a way to atleast allow side by side diff in patch files ? If so, what is the method ?
My aim is to allow emailing of changes so that they can be reviewed before I commit them :)
Mishal
I've never found any, but the solution that I usually use is to simply apply the patch file to a pristine checkout of the tree, and then do a "regular" diff (my preferred tool is diffuse) to review the changes in context.
The problem with "raw" patch files is that they only provide a few lines of context before and after the change, which often isn't enough.
If you don't like the patch, simply revert the changes and don't commit!
Beyond Compare 4 allows you to view patch files created by SVN. The top window in Beyond Compare is a tree structure, allowing you to navigate folders and files by name. Revision numbers are present in the left and right diff windows.
Create the patch
svn diff -r 5922:6116 > CodeReview.patch
Open the patch in Beyond Compare 4
SVN 1.7 I think was released since this answer was posted, and I landed here because I wanted to show my newly created patch file with syntax coloring, a la view unified diff in TortoiseSvn.
It turns out that Notepad++ automatically syntax colors my file correctly if I give it the filetype of "patch"!
Patches have been around a long time but SVN is now supporting them more fully.
See for example the documentation;
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html
For how to create a patch file, see this nice document that describes various methods including mine, WinMerge;
http://docs.moodle.org/dev/How_to_create_a_patch#Creating_a_patch_using_WinMerge
If you have access to a Mac OS X machine, PatchViewer sounds like it might do what you're looking for:
http://appledeveloper.com.au/products/patchviewer/
(Disclaimer: I am the author of PatchViewer.)
You can view a diff file (a patch generated by diff tool) using Kompare from KDE environment. I used it before on Linux, but today I found how to install it on Windows. Here is an installation instruction from a blog "Kompare - the only valuable diff for M$Windows":
Go to gnuwin32 diffutils, download and install.
Download kdewin installer and launch it.
After installing kde4win - start kompare and in "Diff" section show him where your diff.exe (from gnuwin32 diffutils) is located.
Restart Kompare and it's ready to use!
You can also add an association with .diff file format and now you can view any diff files. For me it works great.
I like to use KDiff3, it's packed with functions, very user friendly and available for all popular platforms. It can also integrate with TortoiseSVN.
GitExtensions, my favorite Git GUI, also has an option to "View patch file":
I come from a Java background, and the shop where I currently work refuses to use anything other than MS VC++ to build their legacy project. They don't appear to use any standards for setting up their build environment other than just building it using VS2005 and clicking the compile button.
I was wondering if there was anything closer to what Java had for instance:
A build tool like ANT or Maven
A directory structure that makes sense containing
src - Place for all my source files .c/.cpp/.h
lib - A place for any libraries that might be used in the project (.dll, .lib)
dist - A place for the output executable/distribution of the project
resources - A place for any images/sounds/text files that might be included in the project.
build.xml - Some sort of a build file (my guess would be something like ./configure or MAKEFILE)
Or am I asking too much from a C++ build environment? Is it just always as chaotic as the people in my shop make it out to be? I really have a hard time believing that considering the success of so many C++ projects on the internet.
It sounds like you have good intentions - coming form a non MSVC world I can see your points.
If I were in y our shoes I would definitely make a command line/automated build/build server.
You can use MSBuild for this - and hudson has a plugin for this. I usually have a "Build" directory near the root of the projects that contains scripts/etc that will call the appropriate MSBuild/.sln files.
The "makefiles" for Visual Studio are .sln and .vcproj files. You can call those with msbuild from the command line. You can also export a makefile (I think that is still an option) from within the IDE that you can run. I don;t recommend going that route though other than trying it out and seeing what is output - since that is what you are familiar with.
Both the vcproj and sln files are human readable - go through them - it will give you some useful information.
I would also agree that having a distributon directory is good - for building an installer/etc after the build. Copy all the needed binaries there - either in postbuild steps or in another script/etc.
Let us know what you end up doing.
I have one other piece of advice:
UPGRADE to VC/Dev studio 2008 or 2010. ASAP
MSVC does not impose any directory structure on you. There are some defaults, as mentioned above for the Debug and Release directories, for example, but even these can be overridden on a per-project basis. Use whatever directory structure makes sense to you.
Visual Studio does provide command line support if you don't want to use the IDE. See This MSDN Article for more information.
You can setup a proper build environment using Visual Studio (and for solutions with more than one project, you should), and there are a number of environment variables to use in the project configuration to set so that output files and intermediate files go to different folders than those defined by default.
In our large VS solution, we use e.g. obj/$(ProjectName)/$(ConfigurationName) as intermediate directory and bin/$(ConfigurationName) as output directory in all sub-projects.
All these things must be enforced by the user, and it seems that no single recommendation/best practice has evolved.
The standardized stuff:
The build tool: Visual Studio (doesn't need an extra product)
Build file: *.sln / *.vcproj (*.vbproj for Visual Basic, etc)
Directory structure: "Debug" and "Release" directories for the output binaries.
The rest isn't so much "chaotic" as "doesn't really matter". "Chaotic" suggests that it changes all the time, but in reality you just pick one for a project and stick with it. Companies may have internal standards across projects. It just doesn't matter enough to bother standardizing across companies. C++ is a complex language anyway; anyone with sufficient IQ to read C++ can deal with reasonable variation. The difference between \lib\ and \Library\ won't stop them.
I've got a really large project I made for myself and rece3ntly a client asked for their own version of it with some modifications. The project name was rather silly and my client wants the source so I figured it'd be best if I renamed all my files from
sillyname.h
sillyname.cpp
sillyname.dsp
etc..
Unfortunatly after I added everything back together I can't see any way to change the project name itself. Plus now I'm getting this error on compilation.
main.obj : error LNK2001: unresolved external symbol __imp__InitCommonControls#0
Debug/New_Name_Thats_not_so_silly.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
There has to be an easier way to change all this, right?
Here is a Step by Step on Steve Andrews' blog (he works on Visual Studio at Microsoft)
I haven't verified this, but I've done this a number of times and if my memory serves me right, you can actually use the search-and-replace functionality in VS2005 to rename all instances of the string "X" to "Y" in any type of file.
Then you need to close the solution and change the project (and any other file with the same name regardless of extension) file name(s).
You will obviously need to do a full rebuild afterwards.
I find it always annoying too, to do this manually.
So I tried some tools available by googling- two didn't work (VS C++ here), dunno, if they are more useful for C#.
The following tool worked good for me: I have used the trial version, but I will pay 39,- bucks for it. For me it is worth it. It has also a VS add-in. VS 2013 was not supported directly, at least not mentioned, yet, when I looked:
http://www.kinook.com/CopyWiz
In-place rename didn't work (access error), but "rename-while-copying" worked fine.
But I really wonder, if it is so difficult as some programmers claim. For most parts file renaming and a search&replace of all occurences in all text files in the project dir should be a quite easy and working approach. Maybe someone can contibute what shall be so difficult.
The rational part of my brain forbids the dreaming part to program an own tool- I am lucky ! :-)
You can simply rename the .vcproj or .dsp file and then either create a new workspace (sln dsw) and include the renamed project or simply chnage the name inside the sln file (it's just xml) I can't remember the format of the old workspace but it's still text.
You can either manually rename and reinclude all the .cpp of edit the project file and rename them in there.
sorry don't know of refactoring tool that will do all this but there probably is one.
I assume that in addition to the renamed set of files, you also still maintain a complete "parallel" set of the original files in some other directory, am I right?
Assuming you have both versions, what I would do is:
Get a file comparison tool like Beyond Compare or DiffMerge and compare the old SLN file and the new SLN file side-by-side. Also do this for each "proj" file and any other "config" type files.
It is possible to edit these files by hand. Usually looking at what is different between two copies will help illuminate what you should do to get the second one working.
You might as well start tinkering with the renamed project by hand, anyway, given that it already isn't working. You can't make it much worse. And: you might learn some handy tricks about the XML structure of these files.
Even if you do make small mistakes when hand-tweaking this files, I have repeatedly been very impressed by how Visual Studio handles things. Visual Studio will usually tell you exactly where you got it wrong.