The installation path for Resharper appears different across several different computers we tried. In one, the default location was
C:\Program Files (x86)\JetBrains\Installations
while on other computers it was
C:\Users\my_username\AppData\Locals\Installations
This usually would not be a problem, but however, since we're using dotCover from a batch file we're referencing the dotCover.exe directly, and the part my_username changes with different systems.
Also note that we're only using Resharper Ultimate 2016. I want to confirm if this is intended or not. It is possible it could be problems due to our system, but so far no other program have given varying install paths.
The installation path of R# depends on which installation mode has been used - per-user (LocalAppData) or per-machine (Program Files (x86)). By default, ReSharper installer executes per-user installation, but if one selects Options | All Users checkbox, ReSharper installer will run the per-machine installation. So, it seems as if someone, who installed ReSharper on the first machine, used per-machine installation.
Related
I notice that Microsoft Visual C++ runtime libraries are duplicated all over my computer, eg: at the following locations:
C:\Windows\System32
C:\Windows\SysWOW64
C:\Program Files\Common Files\microsoft shared
C:\Program Files (x86)\Mozilla Firefox
C:\Windows\WinSxS\amd64_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_b157f27efd203c73
C:\Windows\WinSxS\x86_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_553956fb44c2cb3d
Why is this? I thought a specific .dll could only be registered ONCE with windows? Is that not the case? Can you really register the same .dll from multiple locations?
I uninstalled an old version of Skype which had the C++ .dll's in its own folder. But doing so caused a whole load of other programs to break (eg Adobe Acrobat, etc). I fixed it by repairing the C++ 2015 redistributable from Control Panel's Programs & Features window. But while checking the damaged files were re-created and re-registered, I discovered so many versions. How do I know which one is registered with Windows?
If I wanted to write code that referenced those .dll's, which one would it use?
I found a hint of reason for this in this article.
Consider this scenario: you install program “A” and it uses library
version 1. You then install program “B” and it also uses library
version 1, so it doesn’t need to install it – it can just use the copy
that’s already there courtesy of program “A”. Now you uninstall
program “A”. Three things can happen:
It uninstalls the library because it installed it and it should clean
up after itself, not realizing that another program relies on the library. Program “B” breaks as a result.
It never uninstalls the library because another program might be using it. As a result, libraries check in, but they never leave.
We devise some method of tracking how many installed programs are using the library, and only remove it when the last one is uninstalled. Unfortunately, any single program’s failure – be it a programming error or a failure to install or uninstall properly – breaks this technique. At best, you’re left with copies of the library you no longer need, and at worst, uninstalling one program can cause one or more other unrelated
programs to fail.
It’s a mess. In fact, it’s such a mess that most
programs now don’t bother to try and share at all.
Putting Your Fate in Someone Else’s Hands:
Ultimately, application vendors realized that by relying on shared libraries like this, they were putting their fate into the hands of every other application that happened to use the same version of the same library. If only one of them made a mistake, and the library was accidentally removed or updated when it shouldn’t have been, it put all the others at risk.
So, application vendors typically now install their own copy of the
library that they manage and that they can rely on. Disk space is
cheap – much cheaper than the errors and frustration that were
happening when they tried to share.
So now, on my machine, many different applications all carry with them their own copy of the Microsoft Visual C++ Runtime.
And each is more stable as a result, by virtue of being in control of
their own destiny.
However, it remains unclear how dll files can be registered with the same name but from different locations. I did not think this was possible, but perhaps it is.
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
I recently had a hard disk fail on me. I've re-installed Win XP from scratch, updated to SP3, and run the same vcredist_x86.exe that I have always run before to install Visual C++ components. It seems to install... but none of my executables requiring the essential VC++ DLLs will run - they all give the "application configuration is incorrect" message familiar to many of us.
If I run Dependency Walker, I can see that all executables built using VC++ 2005 are simply failing to pick up the likes of MFC80.dll, MSVCRP80.dll, MSVCP80.dll, etc. When I look in the Windows\WinSxS folder, there appear to be folders containing those files in the correct places. These executables ran fine a couple of weeks ago, so I know their manifests are OK.
What could be causing all these applications to fail to run?
Make sure the correct up-to-date version of the redistributable is used and/or matches the versions used to build the executable(s). Note also that the version number of the vcredist_x86.exe file will not be the same as the version(s) of the files installed in the WinSxS folder. This was really useful for shining light on the version issues.
I have some projects built with different versions of VS2005 that require different run-time version. i need to display the assemblyIdentity to see which run-time is required to run the program. I need the information to include the specific VC80 runtime MSM in my WiX installer project.
{Edit}
While the binaries have been built with Visual Studio I don't have a VS on the PCs where WiX shall be used. I am reluctant to install an Express version, since I am a guest on that PC.
{/Edit}
How can I conviniently display the embedded manifest? Preferrable with a small tool, command line tool would be OK.
Manifests are stored as resource in executables/DLLs. These are stored under RT_MANIFESTresource type. Open the resources under it and parse it as XML.
One example is pasted below (I opened one of my EXE using VS resource editor):
The PeStudio is a small tool that does the job. Including displaying the manifest in clear text.
Additionally it displays all DLLs that must be present on target system. That helps to author the installer.
I have an application that uses the ms vc++ runtime. How should I install it on the end-user's system if it is not present? I was thinking of bundling it with the installer... but how would I do that as far as what to include? Is there some silent installer? If so, where can it be found? I can't seem to find it in the Windows SDK.
There is an interesting post about deploying the runtime libraries on the Visual C++ blog. The post is about VC8 so I'm not sure all the recommendations apply to VC9.
Here are your options according to Microsoft:
Use an .msi installer including the .MSM files for the VC
libraries you're using. These MSM
files install the libraries globally.
They also keep a reference count so
that the libraries are removed when
the last application using them gets
uninstalled.
Use "app-local"
deployment i.e. copy the
libraries and manifest files in your
application directory. This is a simpler
solution if you don't use an .msi
installer. Your app should still use the
system version of the libraries if they are more
up-to-date than your own.
Link everything statically (and avoid crt usage across dll boundaries)
Another option Microsoft discourage you from using is running the Visual C++ redist installer from your own installer.
I'm not sure what their reasons are. It will take a few extra megabytes and will not be reference counted but it still works very well AFAICT. You can pass the /q option to vc_redist_x86.exe to perform an unattended install (no user interaction).
It has it's own installation program. I've seen it usually run as a prereq step of a larger installer.
One way or the other, you need to list it in your manifest. So you might just as well deliver it as via SxS in your application rather than try to deliver a global copy to the target machine. SxS is a big hard subject, sadly. Hopefully someone will supply an answer with more details and I'll delete this one.