I am writing a utility that automates some SVN processes. All of the machines that this utility will be deployed to have TortoiseSVN installed - however, they might not be the same versions. I understand that TortoiseSVN is statically linked to a specific version of a SVN library, and that this is upgraded often.
What I want to avoid is having the checkouts that my utility creates and updates be incompatible with TortoiseSVN. My initial idea was to use the TortoiseSVN command line arguments to invoke the dialogs, but they all require user input. I would rather this all be automatic, and the output of the SVN commands be sent to stdout.
Is there any way that I can gain direct access to the SVN library that TortoiseSVN uses internally? Or are SVN checkouts guaranteed to be (forwards and backwards) compatible between minor version differences? Upgrading the SVN binaries my utility uses per major version of SVN wouldn't be too much of a problem. I just don't want to mandate that every user use a specific version of TortoiseSVN.
To those who suggest that I use the command lines tools for SVN:
The clients may not have the SVN command line binaries installed - and even if they do, there would be differences between the version that TortoiseSVN is linked to and the version the command line binaries are linked to - which could lead to incomparability.
You may use the sharpsvn api for direct access the svn server.
It's xcopy deployable and isolated from other svn or tortoisesvn binaries.
I've tried this a few times and the differences between certain versions of SVN code have sometimes been substantial. My guess is that you will have to specify that your code is only compatible with certain version(s) of SVN.
If your application needs are simple, you might be able to execute command line instructions?
Another option would be to try and write your code to read the SVN version, and then handle the differences in your code. That would be a nightmare IMHO.
TortoiseSVN installation has command line tool named TortoiseProc.exe. See "Appendix D. Automating TortoiseSVN" topic in TortoiseSVN's help book (which is included to TortoiseSVN installation as well).
I'm used to a setup that uses TortoiseSVN and also some scripts that rely on a seperate svn commandline client.
In general we don't have issues.
The main compatibility concern is if the working copy format changes.
This happened between svn 1.5 and 1.6.
An svn 1.5 client could not work with a 1.6 checkout.
See:
http://subversion.apache.org/docs/release-notes/1.6.html
On past projects I have also used the TortoiseProc commandline tool - note that it can be called in a manner that removes user interaction if no errors occur see /closeonend in http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-automation.html
I don't believe there is any way to access the base svn client code inside the Tortoise binaries.
Related
I am sorry if this is a repeat but I cannot find what I am looking for by way of the Google (mostly because I don't know what to ask).
tl;dr - Is there a way to make my C# VS Installer project ignore any versioning errors or missing files of previous installs during updated version installs?
Long Version: I have created a C# application that includes 6 files (3 programs, 2 services, and a DLL). I am using a MSI deployment project in VS to create and distribute these files, register the DLL, and install the services. The problem starts when an anti-virus or malware app removes my files (and/or reg keys, services, etc.) from the system. In order to get a new version of my app installed, the MSI must be able to uninstall the old. At this point the install fails because the files or services have been altered and the original MSI package is required. Finding the original can be tricky as my clients typically do not keep them. There were also instances, when I did not know better, when a client needed a custom change to an executable. I would simply change the file and copy it to the users install folder. This further angers the MSI Gods because the file versions are now different than the ones that were put there by the installer. What can I do to easily remove old versions of my application and install the new? I am planning a Major revision and am expecting many headaches over a hundred or so installs otherwise. What else could/should I consider in the future to avoid these issues? What have I failed to comprehend?
Scope: Now that was a lot of questions at once. Firstly, how large is your distribution? How many machines are we talking about?
FixIt: You can try this FixIt tool from Microsoft as a "quick fix", but running that on many computers manually is cumbersome to say the least. Not sure if it can be automated. Never tried.
MSI Uninstall: An MSI does not normally need the original source to uninstall, unless it erroneously calls the ResolveSource standard action or a custom action does something strange. This old answer explains in more detail: Why does MSI require the original .msi file to proceed with an uninstall?
Major Upgrade Uninstall: It could be that during a major upgrade there is some source resolution going on - frankly I am not sure. Did you try to invoke uninstall by its own, manually? In other words run an uninstall command only, and not install the new version on top of the old one and do a major upgrade uninstall? I will run a test when I get a chance.
Section 3 here: Uninstalling an MSI file from the command line without using msiexec
How can I find the product GUID of an installed MSI setup?
Fresh Installation Location: As a workaround you could install your new version in a different place than your old version and de-couple it from the past versions. There could be conflicts in terms of COM servers and other global registrations, but if there isn't you can just leave the old version in place (potentially removing its shortcuts) and leave it there. Emergency "solution".
Self-Repair / Resiliency: MSI "knows" what you installed. It tries to actively maintain that installation state as explained here: Why does the MSI installer reconfigure if I delete a file?. Don't fight MSI - it fights back. Try to follow the paradigm - or you get a ride with the windmill :-).
Virustotal.com: One measure against malware inclusions or false-positive detection and file quarantine is to use an online service which scans your binaries with many malware scanners. Virustotal.com is such a service. Upload your finished setup and maybe also binaries there to see what different tools do to your binaries. Sorry if this is obvious, adding as a tip for whoever else reads this.
Bogdan Mitrache: https://www.advancedinstaller.com/antivirus-whitelisting.html
Section 7 in this answer: How do I avoid triggering MSI self-repair with my WiX / MSI package?
Links:
How to build MSI package on a linux server?
How do I avoid distributing sensitive information in my MSI by accident?
https://devblogs.microsoft.com/setup/resolving-prompts-for-source/
https://devblogs.microsoft.com/setup/resolvesource-requires-source/
I have a windows form c-sharp application developed for windows 10. When I am trying to make installer, I cannot find "microsoft database engine 2010" (important for my app) under the "prerequisite" as shown below:
I do not want my customer to separately download it and install it. So is there a way I can generate an installer that will install complete software along with microsoft database engine 2010 ( if it is not already installed on the system) ?
I have never used this runtime, but did you do a Google search? It looks like the runtime is available: https://www.microsoft.com/en-us/download/details.aspx?id=13255. I am sure you did. Perhaps it is the wrong one? Or a format you can't use I guess.
The downloads are x86 and 64-bit versions in EXE format. The EXE files have embedded MSI files (Windows Installer) that you can extract, or you should be able to just run the EXE in silent mode (probably safest). Do a AccessDatabaseEngine_X64.exe /? to get a list of parameters.
Merge Modules
Normally you can use a merge module to add a runtime component to your own MSI at compile time, but this runtime may not be available in this format. Instead you can use a bootstrapper of some kind to run your own MSI installer and this prerequisite database engine runtime MSI / EXE in sequence (or even just a batch file - see towards the bottom).
Bootstrappers
The WiX toolkit (which is a better way to make MSI files than Visual Studio Installer Projects - see the link for some details) features a bootstrapper called Burn - it can install both EXE and MSI files in sequence. There are also other bootstrappers available, but I haven't tried them. Here is a description of some bootstrappers from earlier: Wix - How to run/install application without UI.
As you will see in the link immediately above, there is a sample of the WiX bootstrapper Burn in use here: https://github.com/frederiksen/Classic-WiX-Burn-Theme (it even shows a WiX MSI package as well). WiX and Burn does have a learning curve.
There may be simpler options available using Visual Studio Installer Projects that I am not aware of, but I think you need a bootstrapper to install several MSI files in sequence. As far as I can see these Installer Projects support only the listed prerequisites that you show in your screenshot to download and install on demand, and they seem to allow the addition of (any) standard merge module. It is very strange that you can't tell the Installer Project's setup.exe to kick off the install of any MSI as a prerequisite considering that the whole feature is made to install prerequisites in the first place. PhilDW will surely be able to tell you with certainty.
Commercial tools such as Advanced Installer or Installshield also have features to allow you to bundle setups, in various formats, together for installation in sequence. It might be a feature in the Premium or most expensive edition in Installshield's case. Not sure for Advanced Installer. Bogdan Mitrache will be able to tell us - they may do it better. I don't want to claim something I am not sure of - things like these change as new versions are released (may obviously also be the case for Installshield).
Batch File, PowerShell Script
In closing I should add that you can obviously use a batch file to install files in sequence (or a PowerShell script - which would depend on .NET though). For example wrapped in a self-extracting archive. You can quickly try the built in iexpress.exe self-extracting tool in Windows: Hold down Windows Key and tap R, enter iexpress and press Enter. Click through the options. Be very aware of the security vulnerabilities iexpress suffers from!
Not sure how well well these wrappers clean up their temporary files (particularly if there are errors during installation) - which could be ugly and annoying, but it should work. A bootstrapper can do a lot more though - such as provide a real GUI for your users and handle error conditions among other things.
Security problems with deployment solutions is a pet peeve of mine, so I want to add a link to this: Prevent DLL Hijacking Burn with Clean Room. A WiX Burn issue fixed in the latest version of WiX (as of Jan.2018). As you can see, the allure and simplicity of iexpress.exe generally does not make up for its security shortcomings. It is most definitely not good enough for a world-wide, large-scale, public release.
Should you want to use a batch file or PowerShell for the installation, then the following answer provides some information on using the msiexec.exe command line, and there is also a link to another answer which deals with PowerShell installation: How can I use powershell to run through an installer?
I'm trying to implement my own feature request to the Visual Studio extension CommitFormatter, and I need the git diff patch for that. I could use libgit2sharp (which I expect to be easy), however, that will pull in an additional dependency. A burden I don't want to add on the extension, if it's not needed.
I expect that it's possible to get the same using one of the APIs of Team Explorer, but I'm a bit overwhelmed with the amount of libraries Microsoft.TeamExplorer.*.dll libraries that Visual Studio contains, and cannot find any good MSDN pages for this.
What I want to achieve is to get the "diff patch" of the staging area, the output that git diff --cached" from the command line gives you, but then using the Team Explorer API. Similar to what libgit2sharp's repo.Diff.Compare<Patch>(repo.Head.Tip.Tree, DiffTargets.Index) would give you.
There is no Microsoft.TeamExplorer assembly that provides a git diff, public or private.
Depending on the version, Team Explorer either uses LibGit2Sharp to interact with the git repository (prior to VS 2017) or uses git (VS 2017).
However, no version actually creates git diff files. The difference view takes the raw files out of the repository and calculates the differences and displays them itself, it does not use patch files as an input or as an intermediate step.
You should either use LibGit2Sharp or call git to produce a diff.
Situation - We have a .net mvc solution with WCF layer. the solution has about 20 odd projects that get compiled into DLL. the site is running on SQL server 2008. we maintain the SQL scripts in the solution folder as versions. So we have SQL scripts eg. version 1.0.0.0 to lets say latest which is 3.0.0.1.
the solution is source controlled in TFS, we also use TFS to manage the work items, bugs etc etc. SQL script files are also in TFS
Question - the question is that do we need version numbers on the assemblied i.e. dlls aswell. Our DLLS are not exposed in any way or from to the outside world they are just in the runtime of the mvc app. we do not expose the WCF to outside clients,again its just used by the mvc app.
the deploy process is simplly the latest code against the latest db, so when we deploy we check what version the db is in and run a tool to upgrade it to the latest version that is in the db project in the solution.
One of our senior architects is saying that we should maintain the version numbers in the assemblies aswell. I am saying that we dont need any version numbers in the code. beacuse TFS manages that. when we release we just deploy the latest code with the latest assemblies/ deploy package.
I have not come accross the assembly versions unless them assemblies where released to the outside world (if you know what i mean)
please can you suggest... Also note we dont do feature development its just version numbers so that we know what version a particular DB is at.
I would prefer the security of knowing and being able to double check versions. If there were a problem with the publishing process, or there were a bug that manifested itself that appeared to be a publishing problem I would want to rule things out as quickly as possible. I also think that it's so easy to implement you've spent more time discussing and thinking about it than you would have actually spent doing it, and there is no down side to it that I can think of.
In a similar project at my job, we use version numbers.
Every commit against the version control system (VCS) causes our CI server (TeamCity) to build a new artifact, with the version set to "LATEST". Every successful build of "LATEST" get deployed automatically to our test environment. We could, in theory, also deploy this "LATEST" version to production, but we don't.
When we want to deploy a new version to production we run a different, manual build job which creates a versioned release (e.g. 1.4.7). The build job also creates an SVN "Tag" of the current codebase. To have our DLLs have the appropriate version, we use TeamCity's AssemblyInfo Patcher feature. This way, we don't have to constantly manually update our projects' AssemblyInfo.cs files. Instead, they get to always have placeholder version info like this...
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]
These number get automatically updated during the build by TeamCity. The versioned artifacts (which include any corresponding SQL scripts) are saved to our "Releases" directory where we keep all our versions of the codebase.
Now this all seems like overkill, right? Not really.
This gives us the following benefits...
Our deploy process does a wget to our monitoring page which lists the version number and asserts the versions match up (version expected to have been deployed vs. the version currently running on the server). This gives us confidence that our deploy process worked properly.
If bugs are found in the versioned release (the production release candidate), we can SVN checkout the tag, apply a fix, and create a new release without having to worry about other changes on trunk which could compromise the release. It is hard to stay "releasable" all the time, this allows to not have to be. Although, don't get me wrong, it has it's advantages.
If problems are found with a versioned release but they can't be resolved quickly, you can always just re-deploy the older artifact which is known to work. Being able to revert a deployed release to an older version has definitely saved us on a couple occasions.
If bugs are found on production that need to be investigated, we are free to deploy the same versioned artifact to any of our test environments so that we can try to reproduce the problems outside of our production environment.
There are probably more advantages I am forgetting at the moment but the above list should give a general idea of the power that proper version management can bring to the table.
What I would advise against is continuously, manually updating 20+ projects' version files. This seems like a lot of busy work which is mostly a waste of time because it is prone to human error. Whatever you decide to do, automate it and verify the results.
I develop application in C# with MSVC 2010 Express, with Forms/WPF/etc.
Application consist of some private assemblies (maybe DLLs) and .exe file. It uses .NET 4 features.
How I deploy this application to other computers? Of course if they have .NET 4 I just can send zip of .exe with .dlls and it work. But if they don't have .NET at all (on Win XP machine)? Or maybe they have lower version of .NET? Should I point them to install .NET from internet or package it with my app or what?
Thanks
There is click-once deploy from microsoft. It automates most of the tasks, including making sure you have the right .Net version and updating the app if a new version of your app is available.
You should create a installer package. If you are using the express versions of visual studio, you can use some free tools for this like WiX or Inno Setup. WiX is perhaps a difficult option to start with, but has a lot of flexibility. There are tutorials and example projects to modify to adapt them to your needs.
http://www.tramontana.co.hu/wix/
This tools create installers that can check if a certain version of the .NET framework is installed on the user computer, among other conditions. You can also include the .NET redistributable in your package, or point the user to download and install it.
We try to keep deployment as simple as possible, and one of the things we do is to ensure our application is just a single executable, no support files needed.
We several steps to get there:
Make sure all dependent resource files are stored in embedded resources where possible, and not on disk
Use ILmerge to link all assemblies into a single executable
Optional - obfuscate the assembly
Optional - If some parts cannot be ILMerged or obfuscated, forcing us to have multiple files, we use Xenocode's PostBuild to link all files into a single executable. Xenocode offers a virtual filesystem to do this. This also allows framework embedding so your app will run on a clean Windows install - no dependencies need to be installed :-)
Wrap the single executable into an msi installer using WiX
Wrap the single executable into click once deployment. For this we also use a little stub launcher executable which starts the main application, allowing us to reuse the same main application executable
Create a zip file of just the single file executable for manual installation.
We the following on our downloads site:
the MSI installer - we prefer people to use this one
A zip file with the Xenocoded (single file) executable
A zip file with the Xenocoded (single file) executable including the .NET Framework
http://support.microsoft.com/kb/324733
Yes, you should point them to install .NET. Otherwise it won't be possible for them to run your application.
You didn't say what type of clients they are (are you making a small app for your friends to use or are they paying customers), but whatever the case may be, I'm always completely against sending a zip file with an instruction document describing what to do with it and what folder to extract it to. As Remy said, ClickOnce is not a bad idea, but I've found it to be a bit of a pain to set up (once you get it set up, though, it works just fine). On the other hand, a Deployment project is simpler and if I were you, that would be the first thing I'd explore.
Use xenocode here
http://spoon.net/Studio/
No need to install anything.
It converts your exe to Native code indirectly and you can run anywhere on windows system.
It also has some option of adding framework inside and the total exe size will be somewhere arround 10MB + Your application exe size..
Thanks
yes! you have to give some general instruction about prerequisites to run your software and in that you can mention the Framework version 3.5 or 4.0 and other utilities you require.
please refer this document for Choosing a Deployment Strategy in Visual studio 2010 may this can help you
http://msdn.microsoft.com/en-us/library/e2444w33.aspx
when you package you application,you shoud include the .NET Framework
Check out Inno : http://www.jrsoftware.org/isinfo.php
It's free and pretty simple.
OTOH I've seen QTTabBar using it in its' codebase and it was literally one single text file (setup.iss). Let me see if I can find URL to their SourceForge page so you can see the source and the build ... There is it http://qttabbar.svn.sourceforge.net/viewvc/qttabbar/trunk/Install/ If you grab the source tree you can probably re-fit it for your app in a day.