The question is at the end - let me start by posing the context:
One of the problem we are facing at work when using Visual Studio is to make sure that everybody on the team is using the same version of the SDKs.
A typical problem would be to have somebody use a different Direct X SDK version resulting in a different behavior of the code, or somebody upgrading to a more recent Platform/Windows SDK in order to use some new API and having the code fail on other's programmers machines if they still use the previous version.
A way we used to solve the issue for other middleware has been to put the whole set of libraries, include files, tool chains, etc... in our source control system, and have our projects to use these so nobody has to install anything.
We also managed to do that with earlier version of the Direct X SDK, but we always ran into issues with the Windows/Platform SDK due to the close links between the SDK and the toolchain.
Since we now have to support both VS2010 and VS2012, and have to support from Windows XP to Windows 8 targets, we have to support v100, v110 and v110_xp toolsets.
This means that we need all the associated compilers and the corresponding SDKs, both on our developer machines and build systems: This is getting ridiculously costly to maintain, specially considering that random windows updates and .net framework releases routinely tend to break msbuild.
So the question is:
Is it possible to have Visual Studio to use non installed toolsets and SDK and instead having it use whatever is available in some folder out of the normal VS installation locations?
Bonus question: If it is doable, is it possible to do that without having to change any locally installed configuration file on the machine - ie: Have all that in the solution/project or property sheets - so if we change the structure on the source control system we don't have to update every single machine?
Thanks :)
This sounds too complicated, given how complex some of these tool installations are. I would solve this problem by investing in some PowerShell scripts that look at the installed tools and tool paths and "police" the installations. It would be relatively easy to check for installed versions of everything, including patches and updates. You can run those nightly, or as part of a build. Also, you can compare aspects of different installations, such as the tool versions installed on a developer box with your build server.
This would give you 90% of the value for 10% of the pain.
The problems you describe are not solved with your approach. What you actually need is a build server and a definition of done including using binaries built with the build server. You also need a test suite as part of the build definition with some invariants related to the build environment used.
Related
I'm looking for Qt packager for my Qt application targeted for windows platform.
I need it to create a nice installer to deploy and distribute my product on windows PC.
Which is best and recommended FREE packager?
For packaging I use the WIX (Windows Installer XML) toolset.
There are several advantages to using WIX:
Free and open-source
Creates MSI files, which allows your application to be easily deployed across large networks and correctly uninstalls (also very important)
Supported and developed by Microsoft, it is used by several other Microsoft teams internally, e.g the Visual Studio 11 Developer Preview installer features some of the latest WIX features
XML configuration allows reuse of components of installers (sets of files, feature sets)
Several types of user interface, new wizard pages can be created
Integrates into Visual Studio
Integrates into MSBuild - can allow consistent packaging to ensure you don't ship debug versions
I have used WIX for installers at work and for my own projects at home.
It isn't as simple as other solutions to get started, but once you've created a simple package, you'll find it easy to add new features.
NSIS is the way to go in my opinion. Straight forward scripting, compatible with all Microsoft Operating Systems and with support for User Levels.
Plus it has a huge active forum for any specific help you may need. I use the HMNSIS editor to write the scripts and have not come across anything it hasn't been able to do yet!
Qt has nothing that can help you, but the free Windows installer package creator is without a doubt NSIS
Inno Setup is a another good, free, light-weight installer system.
There is the Qt Installer Framework. That is a link to the manual for it. It is multi-platform. With it, you write XML files in a directory structure for delivery of components in the directories, called packages. It has scripting. You then compile it into a setup for your target platform.
Correct me if I'm wrong, but I was under the impression that they did not make it available to users of the Community edition until recent versions. When the earlier replies were written, it may well have been commercial version only.
Alas, nothing seems to warn you that you have to collect up components, nor tell you what they are, or even talk about the process; except that the 3rd. party, but free (Windows only), Dependency Walker can tell you what dynamic libraries are being used. I don't find it a necessity, but it can be helpful. (Tip: On Windows anyway, be sure to put "qwindows.dll" in a "platforms" directory with the exe. Tip #2: Make sure the Qt DLL's or static libraries are ones compiled for your compiler.)
Two things come to my mind whenever I revisit the subject of using Visual Studio's compiler and linker to build Windows drivers:
It is not officially supported. Indeed, the consensus all over the Internet is that the right way to build Windows drivers is to use the compiler, linker and BUILD tool included in the Windows Driver Kit. However, Visual Studio 2008 includes the /DRIVER linker option, which is described as follows: Use the /DRIVER linker option to build a Windows NT kernel mode driver. What does it do? Why was it included in Visual Studio if using it for building drivers is not recommended?
It works. I'm almost afraid to say this out loud lest I incur the wrath of the righteous kernel developers, but the truth of the matter is that drivers built with Visual Studio do work. We've been building them this way for years at my workplace, the produced binaries have been deployed on hundreds of machines, and there haven't been any problems. However, I am aware that the absense of evidence is not evidence of absense, and that the lack of any problems so far doesn't necessary mean that building drivers with VS is safe.
What really bothers me here is the lack of information. There are a few posts over the Internet from people who use VS to build their drivers, which invariably draw the same response - it is not supported, do not do it, integrate WDK with VS by means of a makefile project if you really want to use VS's IDE. However, I haven't found a single reply which points out a concrete reason why you shouldn't build drivers with VS.
So, does anyone know what would happen if you use VS to build your drivers? What could go wrong? Under what circumstances? I know that you have to set all compiler and linker options yourself, and it's allright, but what happens if I set them wrong? Will the driver fail to compile, or will it fail to link, or If it builds fine will it crash outright or only when the stars align right? Why would it do that, what causes it? Is there any reason to stop building our drivers with VS which has worked like a charm for years, apart from the fact that it is not officially supported? If it is not officially supported, why put the /DRIVER switch in VS?
The reason this is common-sense is because the resulting flaws can be subtle. Most of this has been cargo cult, though ... ever since there was an actual problem. And if I remember correctly that would have been before 2005 (i.e. the first DDKs at all containing a compiler). Correct me if I'm wrong.
Generally, I don't see a lot that speaks against using the VS compiler though. For the the linker you also have to set the proper subsystem value (i.e. none) and so on ... it's just tedious.
However, keep in mind that the WDK compilers and tools are usually ahead of those in the latest VS at any given time. Consider this: what the WDK contains is a close as you can get to what is used to build Windows itself. Hence the preference for the tools from the WDK.
Technically it can be done. But if you post to a newsgroup and mention the fact, don't be surprised if you first get to hear a lesson on that topic rather than your actual question ;)
If it is not officially supported, why put the /DRIVER switch in VS?
It's not a matter of putting the switch in to VS, it is a matter of taking it out.
The C++ compiler/linker that ship with WDK and VS are built from the same source base (perhaps from different branches and at different points in time, but the same source base), by the same team inside Microsoft. Could they configure their builds so that the /DRIVER switch doesn't appear in the linker delivered with VS? Sure. Is it worth the cost of maintaining a separate build configuration and checking that the right build variants are delivered with the WDK and VS, respectively? Probably not.
As to why it isn't officially supported in the first place... The expertise of validating a toolset for driver development lies within the Windows team, not the VS team. The last thing the Windows team wants to do is to be on the hook to qualify a release of VS for driver development (which Windows would ultimately have to help support, as well), when that release is on a schedule that doesn't line up with Windows.
Combine that with the fact that driver development is targeted at a relatively small audience, and building drivers through IDE opens up additional features and test scenarios, and it is very unsurprising to me that it is not officially supported.
I found Vb6 tools package and deployment. I used it and created a package or setup file from my running vista operating system. Later when i tried deploying it in clients computer with winxp, it asks for update of system file and ask to restart. The process never ends just ask for update and restart. how should i create setup file to avoid this problem?
Edit:
If i create setup file in Win98 and deploy it in clients Vista or winxp then it runs fine...
There is a very good chance you are trying to deploy system files that you shouldn't. Typical examples include MSVCRT components.
You receive multiple "System files are out of date" error messages when you install a Visual Basic 6.0 application
Using Win9x can mask the problem because ancient versions are packaged. During installation either setup1 will detect that newer versions are already in place or Windows will fend them off via System File Protection. Vista is much better at this than XP was.
Yes, the PDW is old. For that reason you should seek out the MSKB articles on usage tips, newer information, and on manually updating the files PDW uses as guidance (its REDIST folder, VB6DEP.INI and the .DEP files that accompany many controls).
Best practices for deploying Visual Basic 6.0 applications is a good generalized starting point.
Many of these sorts of issues have been answered over the years since VB6 and the PDW were released.
The VB6 package and deployment tool is really dated. It doesn't play well with some of the new security features.
It's probably trying to install old copies of the VB6 runtimes and then Windows is restoring its own copies.
It's been a while, but can you remove the VB6 runtime files from the files to deploy in the Package and Deployment Wizard? If so, do so. As long as the computer being installed on has the latest service packs it will already have the VB6 runtimes on it.
If that doesn't solve your problem then check what other system files your deployment project has in it. In most cases you won't need to deploy any system files as modern, patched systems should have them all. There are a few activeX controls that may not be on modern systems, but those shouldn't cause these endless restart problems.
Alternatively, try another install technology. You could create a setup project in modern versions of Visual Studio. Alternatively there are some very good open-source and commercial products.
I've used this one quite successfully in the past:
http://nsis.sourceforge.net/Main_Page
How can I create a setup file in visual basic 6 after completion of my programming work?
Front End language is Visual Basic 6,
Backend : MS Access 2003 and
Report Tools : Crystal Report 8.5. Operating System Windows XP.
You need to be a little clearer about some of this.
"Front end/back end" is really terminology and a thought pattern from the MS Access world. It doesn't really apply to VB6 development in any meaningful way unless you're doing something really odd like automating instances of MS Access.
That's about the only place where any "MS Access runtime" comes in as well. If you're actually using Access Reporting you might be doing this though - which seems odd but anything is possible.
See Deploying Complex Microsoft Office Access Runtime-Based Solutions.
Much more likely what you are trying to say is that you have a VB6 program that is using a Jet MDB as an embedded database, and using Crystal Reports 8.5 for reporting.
There should be no issue about any "runtime" for Jet on Windows XP, since Jet 4.0 is shipped as part of the OS even as far back as XP RTM (gold). It is also extremely unlikely that XP will have an MDAC release any older than 2.7 (see Microsoft Data Access Components (MDAC) release history).
So this leaves you looking for a way to package your VB6 program, any immediate dependencies such as possibly the VB6 runtime components, and the Crystal Reports 8.5 runtime components. You may also have INI files, etc. to bundle in there.
A long, long time ago (1998?) the PDWizard was replaced for most purposes by Visual Studio 6.0 Installer 1.0, and shortly after VSI 1.1 was released (1999?) which made up for a number of ills. This is a pretty basic tool for authoring Windows Installer packages, but it should meet your needs.
Along with this you'll want the recent merge modules for your dependencies: Merge Modules for Service Pack 6 for Visual Basic 6.0 and Visual C++ 6.0.
Then of course you need a merge module for Crystal Reports 8.5, and for this we have to turn to the community because BO didn't start releasing them until CR9. One place to look for this is InstallSite: Seagate Crystal Reports 8. Your real problem is that CR8.5 is ancient.
If this doesn't work out for you, you can always hope that CR8.5 Dev installed on your machine with a "good enough" set of .DEP files (which tell setup authoring tools what subdependencies each dependency has, among other things). This may still let you use VSI 1.1 to succesfully package your application with CR8.5.
You might also look at for-pay packaging tools as already suggested. If desperate enough you might look at some legacy installer technologies too, just in case their communities have addressed your issues.
If I misunderstood and you really do use your VB6 program to automate an instance of the "MS Access 2003 Runtime" you'll probably have to build some hybrid package.
But normal VB programs do not use Access or Access Runtimes to open and work with Jet databases.
You can search google for package and deployment vb6
and you will find millions of links showing in steps how to do that.
The Package & Deployment Wizard is quite primitive and not well-suited to distributing things like the MS Access runtime and Crystal Reports. You'd be better off using one of the more powerful commercial products like InstallShield or Setup Factory. However, these can be pricey (especially InstallShield).
There are also free products like Inno Setup and Nullsoft, but these may not be as easy to use or may lack some important features.
Bob's suggestion of using Visual Studio Installer 1.1 for a Visual Basic 6 application is sound but the Microsoft link he has given for the download does not work. I guess MS thinks nobody needs VB6 anymore. After searching a little I found a 2008 snapshot of MSDN page in web.archive.org complete with setup files:
http://web.archive.org/web/20080513102621/http://msdn.microsoft.com/en-us/vstudio/aa718352.aspx
Good suggestions above.
While it might seem unlikely that VB6 app could possibly be in use, there are those of us in the public sector that keep VB6-like apps and even Access apps alive because public dollars are not in a hurry to replace app that still work. A frequent mantra heard in many places is that you leave it alone if it is not broken. Broken enough that is--otherwise baling wire works just fine as long as VB/VBA developers can still found.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I started trying to play with Mono, mostly for fun at the moment. I first tried to use the Visual Studio plugin that will convert a csproj into a makefile, but there seemed to be no version available for Visual Studio 2005. I also read about the MonoDevelop IDE, which sounded nice. Unfortunately, there's no pre-fab Windows package for it. I tried to follow some instructions to build it by combining dependencies from other semi-related installs. It didn't work, but that's probably because I'm a Windows-oriented guy and can barely spell "makefile".
So, my question is this: What's the lowest-energy way to get up and running to try some Mono-based development on Windows?
I'd recommend getting VMWare Player and using the free Mono development platform image that is provided on the website.
Download Mono
Setup time for this will be minimal, and it will also allow you to get your code working in .NET and then focus on porting issues without a massive hassle of switching machines and the like. the VMWare Player tools will allow you to simply drag and drop the files over to copy them.
I'm looking to take a couple of my .NET apps and make them Mono compliant, and this is the path I'm going to take here shortly.
A year later and the answer to this has change greatly. You can now use MonoDevelop on Windows, or if you are more comfortable in Visual Studio you can use the Visual Studio Tools to write everything and then debug on in VM to make sure it is working on Linux.
#Chris I have found that Visual Studio is the best IDE for developing against .NET -- I think the best way to target Mono is really just to develop and build in Visual Studio under Windows then just run those binaries directly on Linux (or whatever other Mono platform you are using). There are free versions of Visual Studio if licensing is a concern. If you are developing under Linux, the best software is probably Eclipse with a Mono plugin (see The Mono Handbook - Eclipse for installation instructions) but keep in mind it doesn't have near the amount of features or language integration Visual Studio has.
#modesty Mono is a 3rd party open source implementation of the .NET framework which allows you to run .NET applications on platforms other than Windows.
One of the best things you can do if developing with Visual Studio for Mono is to get MoMA http://www.mono-project.com/MoMA. This will inspect any number of assemblies that you build and generate a report showing potential Mono problems (e.g., methods not implemented in the mono library). It can be run from a GUI or the command line for use in automated builds.
Miguel had a post about debugging Mono running on linux with remote debugging on Visual Studio. This may be something you want to look into... Using Visual Studio to debug Mono. There is also a new project called CloverLeaf whose goal is enabling debugging Mono on Windows in Visual Studio.
There's just no reason to build your app using Mono; the whole point of the .Net CLR is that the compiled output is cross-platform.
So you can simply build it using your favourite IDE (and if you like IDEs, Microsoft's is the best one to use) and then test it on Mono. Even if you get Mono working on Windows, it wouldn't be a very good test of your app's portability: what if your app does silly things like assuming filenames have backslashes in them, or that there's something special about a folder called Program Files? The best way to do portability testing is to actually test your app on the target platform.
And that's pretty easy to do with a Linux VMware player like the one at http://www.go-mono.com/mono-downloads/download.html.
Personally, I'm just compiling in Visual Studio 2008 as if it were for .Net 2.0 and then running in Mono (VS2008 on Windows in a VirtualBox, Mono on OSX). All the problems come up at runtime, anyway, so the system works perfectly.
I just found this very new link, which is amazing and shows you how to set up Visual Studio 2008 for Mono.
At the same time, setting up Mono on OpenSuse or Ubuntu inside a VirtualBox (Sun's product) is easy, painless, and doesn't force you to abandon whatever platform you normally live in.
This is not relevant to your question, but I might note that I just got into Mono and I'm amazed at how much of .Net is implemented, including much of the Winforms stuff.
My first instinct would be the rather unhelpful "Install Linux". You are somewhat swimming against the current to try and develop in mono under windows. Installing GTK and everything is a bit of a bother in my experience.
If you do feel like using linux, then you could Try Ubuntu
Otherwise:
There's some information here: http://www.mono-project.com/Mono:Windows and it seems the cygwin toolchain might be your best bet. I don't think you're going to be able to avoid makefiles, sadly. I found a slightly more explicit tutorial from O'Reilly.
#modesty: Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications. -- From the Mono site.
Eclipse plugin for Mono is dead. On Linux use MonoDevelop or X-Develop if you like good commercial support (although MonoDevelop is closing on them fast feature-wise). On Windows SharpDevelop has custom MSBuild targets for compiling the code against Mono.
As Mono and MonoDevelop are changing fast, be sure to use the latest released versions, even if they are not marked as stable yet (e.g. versions shipped with stock Ubuntu are terribly outdated).
The VMWare image is a great way to start testing Windows-developed code on Linux. Don't touch cygwin unless you are already very conformable with it.
I liked the idea of trying to use MonoDevelop mostly just to make sure my stuff would work against the Mono runtimes. I guess it would also be possible to get crazy with msbuild and write some custom targets that tried to build against Mono, but that's basically emulating the now-defunct plug-in's functionality which I assume was non-trivial to build. I do have minor experience with cygwin, and I am happy typing "configure" and "make" all day long, but when a problem occurs in that process, I'm virtually screwed. I'll probably try to play with all this again, but if it takes me more than a couple hours to come up with a way to build comfortably against the Mono runtimes, I'll probably just bail.
I will try the Eclipse idea. I use that for Java, so I might be able to get the c# stuff to work. We shall see...