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.
Related
I've built a project using VS Express 2012, and obviously there are no installer project templates available for me to use to create a setup/installer routine.
I've looked up some alternatives and have found NSIS and WiX, but I'm not too sure about the details of these.
My project uses an MS Access back-end, along with Crystal Reports files, .ini files, and infragistics controls...
Which of these, if it's even possible, will make it possible to create an installer that means the end user doesn't need to have the infragistics package etc installed? Are there any better alternatives?
If you use the Infragistics binaries then there is no way to run your project if the running machine has not the infragistics binaries available.
You need to distrubute them along with the required binaries for Crystal Report.
With Access the problem is different. If you use OleDb.Jet.4.0 (Access 2003 32 bit) then support is included directly in the framework. If you use ACE.12.0 then you need to install the required binaries from Microsoft (https://www.microsoft.com/en-us/download/details.aspx?id=13255) and be sure to read The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine while data export to MS ACCESS
I've been trying to figure out on how to setup a Cross-Platform project for MonoGame. Whats the conventional way of doing so ?
Is that done through a Shared Project and can I keep all my content in 1 project ?
Also I am not sure if this information is correct do I need a Mac to build my project for Mac how does that work ? If so how what's the best way of setting that up.
Targeted Platforms : WINDOWS, LINUX, MAC
The best way to setup a cross platform MonoGame project IMO would be to use a Shared project. Shared projects can also include .mgcb file so you won't need to duplicate your content either. How to do:
Use "Xamarin Studio/MonoDevelop" and create a "MonoGame Shared Project" with the name of your game
If you are going to use using "Visual Studio", close the "Xamarin Studio/MonoDevelop" after this, and open up the created project vith it
you are gonna have to include the generated "Content\Content.mgcb" file with build action "None" so it will be visible in Project View area
Add a MonoGame Project for the platform you wish to launch the game from, ie. create a "MonoGame Crossplatform Project" and name it "(gamename).DesktopGL"
Delete "Game1.cs" and "Content Folder" from the Platform project
Add a reference for your Shared project
For your platform project, in options set the Output Assembly Name to be the same as your shared project
this step might not seem important, but if you are using a custom importer/processor this will allow you to not have to compile the content separately for each platform.
There you go, you should be able to run your project now.
Also I am not sure if this information is correct do I need a Mac to build my project for Mac how does that work ? If so how what's the best way of setting that up.
The created executable from DesktopGL project is runnable on Mac even when compiled from Windows, the Mac user just has to launch it using Mono. In case you want you can package your game using MonoKickstart so that your Linux and Mac users don't have to have mono installed: https://github.com/MonoGame/MonoKickstart what's more, it also includes other needed native libraries. Description on how to use it are in the link.
Since you're just targeting Windows, Linux and Mac, you can use Xamarin/MonoDevlop which runs on all three of your target platforms.
Once it's installed, then add the Monogame through the Addin manager. The addin on version 5 of Xaramin and MonoDevlop.
You can then use the same Solution project file between all three platforms assuming you use the OpenGL Template. I use this method for developing between Windows and Linux.
The only time you'll need to use a shared project or something similar would be if you started developing for Mobile (iOS/Android) or for Windows on DirectX instead of OpenGL.
I have been a long-time visual studio developer, and I am trying to switch over to using mono so I can port my applications to Ubuntu. I have been trying to get some of my VS2010 C++ projects (.vcxproj file types) to load into MD on my Ubunutu 12.04 machine. According to the documentation I have read online this should work, however, every time I try and load a project I get the error shown below. Is there something else I need to be installing in order to be able to load C++ projects in monodevelop? I have done some searching, but have not yet found anything related to this particular question.
VC2010Test.sln(4): Unsupported or unrecognized project : '/home/me/Projects/Test/VC2010Test/VC2010Test.vcxproj'.
Thanks
MonoDevelop has a C/C++ binding, called CBinding.
But:
Beware, it's not meant to target managed C++.
AFAIK, it only works in Unix-like platforms.
So, if you still target non-managed C++ and are not using MonoDevelop for Windows, two questions:
Did you make sure that the binding (addin) is installed and enabled?
If the answer to the above question is yes, you may want to try this: the binding creates projects with the extension ".proj" by default, I think, so maybe you can change this to ".vcxproj", recompile, and test again. If it works, then it should be easy to create a pull request to include this extension of possible file types that this addin can handle?
I have a Visual C++ library which I want to compile for a certain platform (I try to compile POCO for a Win CE ARM platform, but that might not be relevant to this question). I got a vendor-specific Windows CE SDK (including all common Windows include files e.g. winbase.h) which is set as target platform within the Visual Studio project files. However, when I compile the program, I can see from the error log that the default Windows 6.0A SDK is used, resulting in a bunch of compilation errors.
I guess the WindowsSdkDir ist not set accordingly - I thought this would be automatically overriden when setting the target platform within Visual Studio.
So my question is: can I modify the WindowsSdkDir for a single project explicitly?
Thank you in advance
Which CE version, which VS version and on which Windows version? I know that I had problems installing CE5 and/or CE6 SDKs and getting them recognized by Visual Studio 2005 running on Windows 7 (64 bit). I don't remember the exact symptoms and fix, but you can test that by simply creating a smart device project for the target SDK.
If that is not the issue, there is also the pitfall with the target in both the project file (.vcproj) and the solution (.sln). You can change both independently from each other, up to the point where you compile the x64 debug version of a project in the win32 release version of the solution. Verify that these setting match.
Then, if you adjusted the .vcproj file to use your target platform (for which I personally would use a text editor), things should work. If you need to adjust the build or some paths, you can sometimes get by with e.g $(Platform) in the compiler/linker settings.
Lastly, if all that doesn't work, there are property sheets, which can adjust certain settings. You then create a property sheet once and then load it into the project that you want to compile. I'm not sure if you can change the target platform or the SDK paths with that approach though, and I'd rather try to find out why the SDK doesn't work and how to fix it instead.
I'm developing in an environment that is severely constrained, but the developers also have tight control over.
VCRedist_x86.exe - A 4Mb redistributable - is no fun (four hours to transfer). I'd really prefer to just redistribute MFC90.dll, msvcm90.dll, msvcp90.dll and msvcr90.dll - that's more like 2Mb. However, Redistributing Visual C++ Files says:
It is not supported to redistribute C/C++ applications that are built without a manifest. Visual C++ libraries cannot be used by C/C++ applications without a manifest binding the application to these libraries. For more information, see Choosing a Deployment Method.
My original plan of copying the DLLs into the program's working directory doesn't seem to
work in this brave new world of manifests.
My next guess is to bodge up the registry entries required to populate the files into the WinSxS directory and populate it myself (rather than using the 4 meg program).
[edit] The software is frequently updated, so DLLs are strongly preferred to static linking. [/edit]
How can I sucessfully distribute the necessary files but keep the overhead down?
[I'm the current SxS maintainer at Microsoft]
I would strongly suggest against removing the publicKeyToken attribute from manifests. Private deployment of the dlls will work just fine with this attribute left intact.
However, removing it will prevent your app from benefiting from security updates should there be a newer version of the CRT installed centrally on the target machine, as the dependencies will no longer match up.
So, to summarize: it's safe to embed your manifest, with the default. Copy the CRT manifest + DLL files directly into your executable's directory, with no edits. That's it. Compatible Win2k+.
We use this: Howto: Deploy VC2008 apps without installing vcredist_x86.exe
Essentially
Don't embed a manifest in your exe files.
Copy the C++ DLLs and their manifests to your app's directory.
Remove the "publicKeyToken" from all manifests (yours and Microsoft's).
If necessary, change the version info in your app's manifest files to match the Microsoft manifest files (or vice versa)
Specify /MT (Multithreaded) for the "runtime library" setting in the compiler property page. This statically links against the runtime library so you don't have to install the redistributable.
Install them as private assemblies. See here:
http://msdn.microsoft.com/en-us/library/ms235291.aspx
Note that if you don't need all of the DLLs provided you can modify the manifest files to only reference the ones you need.