I'm very new at C++ Managed and Visual Studio keep this in mind. Ive programmed an application that makes it easy for users to bind keys in counterstrike, found here:
https://sites.google.com/site/intrepidprojects/
The first error I ran into with my friends testing the program was "msvcr120D.dll is missing". Which lead me to finding that I have to set the runtime library to Multi-threaded (/MTd), if I don't want the users to download the Visual Studio c++ dll's . When I choose this option I was given the error that /MTd and /clr are incompatible. So I turned the common runtime support to no support. Now all of the namespaces are invalid such as 'System', 'Collections', etc.
My question is how do I produce a stand alone application without needing the dll's? Every solution I have come across leads me to more errors I do not understand.
Again, the language I am using is c++/cli. Sorry If I am not using the proper lingo to communicate my errors I am teaching this on my own.I am aware that this question has been asked many times before, but the answers are not leading me to solutions.
My question is how do I produce a stand alone application without needing the dll's? basically: you don't. Just have them install the CRT runtime - the'll need it anyway sooner or later as you're not the only one writing programs targetting that toolset (btw, you tagged the question VS2012 but those dlls are normally for VS2013?). As an alternative you could look for all the needed dlls (msvcr120.dll, msvcp120.dll etc, use Dependency Walker) on your filesystem and put them in the same directory as your executable, that works as well because of how the path is searched for dlls. But it's a bit messy.
Furtermore missing msvcr120D means you are building your project with the Debug configuration (that is what the D stands for), but you should build with Release configuration when shipping to users as the runtime installer only installs release versions.
Select MT without DLL in VC++/C Code generation section in solution properties. Worked for me.
Related
Is it possible to get editbin.exe installed on a build server (running TeamCity 9.*, although I don't think that's particularly relevant) so that we can modifiy the TSAWARE flag of a C# exe after it's built?
It appears that our only option is to take a code-based approach (https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.vcprojectengine.vclinkertool.terminalserveraware.aspx), and I'm not even certain that's a possibility since it appears to just use a .Net wrapper for the C++ linker, which is the whole problem here. If I could do that, I could just set up the project to set the linker option, but since we're using C#, there is no C++ linker.
I'm fairly certain that, even if it worked, copying editbin.exe from a developer workstation isn't permitted by the EULA, and we'd rather avoid needing to install VS (properly licensed of course) on the build server.
Install Visual Studio Express. This edition comes with the C++ Tools.
Don't know if this is 100% compliant with the eula.
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
I developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
I have a VB.Net 1.1 application works just fine after compiling in Visual Studio. However, I want to use ILMerge to combine all the referenced assemblies into a single executable just to make it easier to move around. After I send it through ILMerge and try to run it I get the error
"Strong name validation failed for assembly.exe" .....
But none of my stuff is strong named! I saw this post here: Strong Name Validation Failed and tried running it through 'sn.exe -Vr merged.exe' but that gives me this error:
"merged.exe does not represent a strongly named assembly"
Has anyone else had this problem before? How do I fix it?
UPDATE:
I'm starting to feel like Strong name validation isn't the real problem here. I'm building against .NET v1.1 and running on a machine where that is the only .NET version installed (happens to be Windows 2003). The merged executable appears to die with that error on every Windows 2003 machine I try, but if I try to run it on a more modern OS (Vista) it at least starts, but that's not really a good test since the environment isn't fit for a real test.
I have verified that my app.config has the correct settings (specifying required and supported runtime version of v1.1.4322)
I use the /targetplatform:v1.1 option when running my assemblies through ILMerge.
ILMerge is definitely causing the problem (i.e. it works fine before I merge), I just don't know how to fix it.
I had to find and download a very old version of ILMerge (v1.1) in order for my merged binary to work; there must be a bug in the way the current ILMerge application builds .NET 1.1 assemblies. Thankfully we had one internally because I would probably have never found it online.
Can anyone explain what advantages there are to using a tool like MSBuild (or NAnt) to build a collection of projects versus running DevEnv.exe from the command-line?
A colleague I had worked with in the past had explained that (at least with older versions of Visual Studio) using DevEnv.exe was much slower than the other techniques, but I haven't read any evidence of that or if that is now a moot point now that starting with 2005, Visual Studio uses MSBuild under the hood.
I know one advantage of using MSBuild allows you to build your projects without requiring Visual Studio to be installed on the build machines, but I wasn't sure if there were others.
One reason is because there's much more to building a product than just compiling it. Tasks such as creating installs, updating version numbers, creating escrows, distributing the final packages, etc. can be much easier because of what these tools (and their extensions) provide.
While you could do all this with regular scripts, using NAnt or MSBuild give you a solid framework for doing all this. There's a lot of community support for both, including additional tasks that can be downloaded (such as the MSBuild Community Tasks Project). Plus, there's support for them in numerous third party and open source products.
If you're just interested in compiling (and not the entire build process), you may find one time saving benefit of MSBuild is the support for building with multiple processors.
The obvious answer from my team is that not everbody has visual studio installed, in particular we do not install Visual Studio onto our build/CI servers.
The prime reason for using an external build tool like NAnt or MsBuild is the ability to automate your build process and thus provide continous feedback on the status of your system. Also they can be used for loads of things besides a "pure" build and that's where you really start to get value from them, it's an extremly valuable thing to be able to build and test your application with a single command.
You can also start adding stuff like collection of metrics, packinging of release binaries and all sorts of nifty stuff like that.
As far as C# goes, devenv.exe 2005 runs the compiler in-proc, which may cause out of memory exceptions for sizable solutions. Msbuild resorts to launching csc.exe process for each project. Projects that don't compile with devenv /build work fine with msbuild. Hope you like this reason.
We are experimenting with switching from DevEnv to a tool (Visual Build Pro) that uses MsBuild under the hood and we got a "Reference required to assembly 'System.Drawing..." error for a project which doesn't need it and which builds fine in Visual Studio.
We have a large system consisting of C#, managed C++, and plain old unmanaged C++ assemblies/dlls. There is C++ code that depends on managed C++ code that depends of C# code that depends of managed C++ code that depends on plain old C++ code (whew!). When we were setting up our automated build environment a few years ago we discovered that MSBuild.exe didn't properly handle all of the dependencies that we have.
Working with Microsoft we were able to solve some of the issues but not all of them. If my memory serves me, we never could get the C# assemblies that depended on managed C++ dlls to build. So we ended up making a custom build script that called devenv.exe from the command line and it worked just fine.
Of course, that was with VS2005, it might be fixed now, but the script is still working so we haven't revisited the issue.