I've written a new Visual Studio language service for my software studio's internal scripting language following the directions from a very useful article Writing Your First Visual Studio Language Service. I've got my grammar working great, some simple goto cases up and running, and text coloring. I've done my testing both in the Irony GrammarExplorer and the Visual Studio Experimental Hive, and I feel I'm ready to use it normally in visual studio and deploy it out to a few other programmers for some early testing and feedback.
The problem is I don't know how to install the language service. I have this nice little DLL that works in the Experimental Hive, but no clue how to have it running whenever I start up visual studio. I've looked all over the internet and found that particular step is glossed over everywhere I look. Maybe I'm just blind, or it's much easier than I think it to be, but I'd really appreciate it if someone could give me detailed steps on how to install my language service.
Thanks in advance!
After getting the Tumbleweed badge on here I managed to track down the solution. There were a couple important bits people might find useful.
First off a PLK (Package Load Key) is needed. It can be generated here: http://msdn.microsoft.com/en-us/vstudio/cc655795.aspx
Be sure to make sure that all the information you enter is correct, and is entered into the Assembly for the dll.
The PLK is installed by adding to the rsx file for the solution, usually as item 104, and then matching that item number in the ProvideLoadKey attribute in your code.
Next testing the PLK is a bit of a hassle. Tips can be found here: http://msdn.microsoft.com/en-us/library/bb164677%28v=VS.90%29.aspx I highly recommend first using the /noVSIP switch with the experimental hive right from the start. I found using /log doesn't really help, it's much better to use the Package Load Analyzer once you've installed your package and are still having PLK issues.
A more detailed description from the package load analyzer can be done with this command line:
devenv /command tools.analyzepackage /analyzeargs {your GUID} analyzepkg.txt
Once you're satisfied and ready to deploy, there is a tutorial that seemed more buried than it should be over at MSDN http://msdn.microsoft.com/en-us/library/bb458038%28VS.90%29.aspx
One thing that I found was curious with the RegPkg tool found in the VS SDK bin directory was that it would cause my package to load fine in the development solution it existed in, but would not not load in other solutions. There appears to be an extra step to call devenv /setup which I was missing, and this is taken care of in the deploy tutorial I provided in the previous paragraph through the use of a Custom Action.
Anyway I hope this helps someone running through the same process as me.
One other thing that I spent a couple of hours bumping into that the MSDN tutorial doesn't mention: If you're deploying to a 64-bit computer, the instructions as given won't work. After quite a bit of searching, I stumbled across a posting halfway down this forum thread that explains it: http://social.msdn.microsoft.com/Forums/en/vsx/thread/989c5bea-3dd0-4e60-891a-f8f006e1b9a2
The MSDN tutorial says to install your registry keys here and regpkg.exe generates registry keys here as well:
HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\9.0\...
But on 64-bit computers, Visual Studio loads its settings not from there but from here:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\9.0\...
Notice that extra "Wow6432Node" in there; the registry keys are otherwise identical but for that extra "Wow6432Node" in the path. So on 64-bit machines, you'll either need to use those extended registry keys, or you can install a hybrid 32/64-bit .dll to both sets of registry keys without ill effect. I have a .reg file that installs to both sets of keys, and it works very nicely.
Hope this helps save somebody else some time!
(For what it's worth, I used the "Codebase" mode for regpkg, not the "Assembly" mode.)
Related
Has anyone got any experience in doing this?
Specifically, I'd like to find out if any registry keys are being written and what files are going where when I run an MSI.
I was thinking of using ProcMon to see what the msiexec process is doing while I run through it but just thought I'd run it by here to see if anyone has a better method.
Bit rusty, but here's a few (maybe) helpful pointers.
There is a tool called Orca that you can use to edit MSI files.
There was also Wise for Windows, which is now called something else, and I'm not sure what you'll be able to do with the trial, it definitely had the ability to edit MSI files.
I was going to suggest FileMon and RegMon on their own, but I just saw they've actually been merged into ProcMon, shows how behind the times I am :)
Ideally, the setup author used only the Registry and COM tables so it's very easy to just look with Orca what's being done. However many setup authors produce less then idea installs. In those cases I use InstallWatch to snapshot the registry before and after to generate a difference.
InstallWatch Pro
You'll see other line noise from processes running on the machine but you learn to filter those with experience. ( E.g. the install didn't change the crypto seed or the MRU's and ShellBags )
I just came back to C++ Builder after 5 or more years away. I seem to remember a nice tool where I could drag its pointer over the GUI of my running application and get lots of info about what was pointed at - handle, size, text, parent, children, etc
IIRC, if the exe include debug info I could also get the actual variable name as used in the source.
Does anyone know what program I am talking about? Thanks
There are several options:
Winspector
This is the program I've used the most of these Spy++ like programs, it has all the features I needed and worked without complaints on my developer machine, it has been quite some time since I've used it though. And the official site seems to be down for some reason ( http://www.windows-spy.com/ ) but luckily you can get a version from softpedia: http://www.softpedia.com/get/Security/Security-Related/Winspector.shtml
WinSpy
I have used this program for debugging, and finding out which messages was sent to different windows, it worked quite well, and was a good alternative to Spy++, besides it is free. You can download it from here: http://www.catch22.net/software/winspy
SpyStudio by Nektra
I have never tried this program but it actuall seems to do what you asks, and it is free. It can be found here: http://www.nektra.com/products/spystudio-api-monitor/
(source: nektra.com)
WinID
From what I've heard WinID should be able to perform much of the same, but I have never tried the program myself. You can download it from here: http://www.dennisbabkin.com/php/download.php?what=WinID this program is not compatible with Windows Vista though (and probably not Windows 7 either).
The challenging option
If there is a bit of a pioneer in you, you might want to create your own utility, although this is most likely not what you want, but if so you can check out these codeproject pages:
http://www.codeproject.com/KB/graphics/screen_capturing.aspx
http://www.codeproject.com/KB/dialog/windowfinder.aspx
These are all a lot like the Spy++ program that came with Visual Studio. Last but not least you might find other programs in this thread: I want Spy++ but I don't have Visual Studio
A very decent effort to revive the beloved but defunct winspector is window detective : http://windowdetective.sourceforge.net/
What you describe in the question sounds like TestComplete. http://www.automatedqa.com/products/testcomplete
If you compile the application as an "open application"(you add a few .pas from TestComplete to the project) then it will use the debug information and you will be able to see private data members of the classes and their value.
Although NSIS allows you to build quite powerful installers, the "so low level language that it reminds me of assembly" that NSIS uses is quite prone to making mistakes and therefore, when you want your installer to do something more complex other than writing files, debugging is a must.
Until now I've used the following Dr Printf-like debugging technique:
In a .nsh file that I include everywhere, I define a NSIS_DEBUG_MSG macro according to the value of a DEBUG define
if DEBUG is on, the macro will trigger a MessageBox with the debug message
if DEBUG is off, the macro will do nothing
This method has served me well but it presents some disadvantages:
it requires me to fill the code that I feel it's the one failing with calls to NSIS_DEBUG_MSG and rebuild the installer several times until I get enough info to allow me to solve the problem
it will do me no good if my problem is that the installer itself fails (if the installer program dies)
So what I wanted to know is what debugging methods do you use for these installers so that hopefully I can improve mine.
During my time using NSIS, there is these things noticeable:
I have found out that nothing is more powerful than parsing !verbose 3 level output with self-made tool ;)
I have found out that you can NOT depend on any NSIS-based debugging method. It may crash .. and your installer will crash along with it. No pretty, eh'? :(
I have found out that enabling/disabling debugging on-demand is also very powerful weapon against idsses as it allows to distinguish between unstable and failed NSIS build ( it is easier to use CI terminology though... :) ).
I have found out that verbose output w/o realtime automated NSIS testing is like driving Cadillac with bicycle engine :)
Hope it helps for those accidentally visiting this question :)
EDIT: It's always good idea to start with 3rd party tools. For example, no need to hassle around GUI as it is always easier to use tools like:
EclipseNSIS ( I do not like it though :P )
NSIS Dialog Designer (http://nsis.sourceforge.net/NSIS_Dialog_Designer)
Self-made static code analyzer. I have made one for myself :P
EDIT #2: I have found out that pretty effective method for debugging is to use direct documentation automatization. Currently I use the following components:
http://nsis.sourceforge.net/NsScreenshot_plug-in ( See IMPORTANT NOTES to have no unexpected surprises... )
http://www.dokuwiki.org/cli#dwpagephp ( See this link for more information: http://www.microsoft.com/web/platform/phponwindows.aspx )
The result is that I got screenshot after nsDialog:Show plus I got updated images in wiki :) .. only stuff left is to fetch info from svnlook :)
EDIT #3: And the need of svnlook is also worked-around by building a svn log --xml exporting DLL using NSIS v2.44 header for Delphi and Lazarus IDE 0.9.30.2 :) Kudos to Lazarus!
Woohoo! :)
EDIT #4: Hit this small discussion here: http://forums.winamp.com/showthread.php?t=325521
What have saved me much time is to use the logs that are created by NSIS. Both the log while compiling the scripts, and the installation log. They allows me to check that the macros I have defined is in use, and that the installation actually run the scrips they should.
It might seem too little, but this is actually everything I need to keep my installation software of 50+ nsh files running, along with the divide an conquer principle.
You can download one of the special builds of NSIS from the official site that has advanced logging. This will give you very detailed logging information that makes debugging easier.
I use the DumpState plugin a lot, much better than a basic messagebox for stack issues. I alse tend to use a macro that sets all registers; $0=r0,$1=r1 etc so I know the stack is in the correct state. This is of course only useful during the design phase and not so much for debugging on the end users system...
Does anyone know of a whirlwind tour of Eclipse that would help a (former) Visual Studio user get up to speed with it?
I just want something that tells me where all the basic features are and what all the cool stuff I've heard so much about is?
So far I've been using it mostly as a text editor and have had some luck compiling and running programs in it. But... I'm a bit confused, for instance sometimes I can't seem to get out of debug mode.
I'me sure I'm just looking in the wrong places for everything as I'm used to a different interface.
Are there plugins for Eclipse that make it look and feel more like Visual Studio?
I'm using Europa at the moment because thats what the rest of my team use, howver I'm more than happy to migrate to Ganemede...
Try Help -> Help Contents (no joke) and read the Workbench User Guide:
Especially the Chapter Concepts.
The same chapter is also very well in the Java Development User Guide
I'm sure after reading these few pages, you'll already know more then the average Eclipse user (because needs Help this days?).
Try http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/welcome.htm if you can't access the help directly from Eclipse.
Also IBM have an Introduction to Eclipse for Visual Studio users (although I've never used visual studio so I can't gauge it's usefulness).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Heavy emphasis on simple. I've never made an installer and I'd rather not have to learn much. A system that I could hand a pile of files to and it would make some smart guesses about where to put them would be ideal.
Go ahead and answer the general question.
However In my cases I'm stuck with some extra constraints. The program to be installed is written in VB6 (or is it 5?) and a few previous versions of VB, so it's not going to be updated any time soon. I have a running install and will have a Clean VM to play with So I'll be doing a loop of: run the install, find where it's broken, fix it, add that to the installer, revert the VM, try again. If anyone has a better approach I'm open to suggestions.
I MUST get it working on XP and I'd really like to also have something that will work on newer versions of Windows as well.
InnoSetup or NSIS, whichever seems easier to you. ISTool is a nice GUI tool for InnoSetup which makes creating setup scripts even easier.
I've used InnoSetup several years ago, before Vista, and was very happy with it then. I only had a few files to install and a Start menu icon. It worked great, and was easy to learn.
Dependency Walker is super useful for finding out which dll is missing from the installer. Once you know the dll, you can find what merge module it is in using the Merge Module Finder.
I have worked with NSIS and getting past some of its minor complexities its a fantastic system. its free, offers tons of plugin ability and managed to do everything I needed to do.
Creating a full setup package for a program is almost a subject area in itself. There are many factors to consider and most of us aren't running Windows 95 anymore. The world is not as simple as it once was.
There are a lot of things that need to be addressed, and some of these "setup" issues mean changing the program too. For example the "protected folders" concept that seemed to be new to people when Vista UAC came on the scene. I guess they were all running as admin or something? In its simplest form it means you don't put writeable files next to the EXE in Programs (aka "Program Files") anymore.
Another factor is that the way the registry is used has changed. I'm not talking about registry virtualization, though that's part of it as well. But COM registration can be done both per-machine and per-user and even turning UAC off can muck this up. See Per-User COM Registrations and Elevated Processes with UAC on Windows Vista SP1. The result is that a setup package shouldn't be running regsvr32 (or otherwise calling the self-reg entrypoint of a COM library). See "Remarks" at SelfReg Table.
Windows Installer is the way to go forward in most cases. VB6 programmers have Visual Studio Installer 6.0 version 1.1 available as a free download for creating MSI packages. See "COM Servers" at the VFP article Using Microsoft Visual Studio Installer for Distributing Visual FoxPro 6.0 Applications for some valuable information.
This isn't the easiest option but there is a VB Setup Wizard in VSI 1.1 to help get the basics right. Doing advanced things like creating a [CommonAppData] subfolder and setting Everyone rights on it has to be done in a post-build step outside the IDE. That's where 3rd party tools can be useful to give you more control without resorting to Orca or post-build Installer scripts.
Those guys making scripted "legacy" installers try to keep up, but the scripting gets more and more complicated. The results are sometimes iffy. Windows 7 introduces a few new wrinkles of its own.
While ClickOnce isn't really the best option for VB6, nothing says you can't use reg-free COM for XCopy installs of many programs. Reg-free COM can even be a good option for use in an Installer package for that matter.
So in the end the "simplest" way to deploy VB6 programs is probably going to be reg-free COM XCopy packages wrapped in a self-extracting EXE that will fire off a script to create a Start Menu shortcut. If you can live without the shortcut this is even easier: just unzip the package where it needs to go!
See Make My Manifest or alternative tools for reg-free COM packaging.
This requires that the target systems be running XP (preferably SP2) or later. The only possible glitch here is that XP did not include the VB6 SP6 runtimes until XP SP3, so you'll want to test your program against the VB6 SP5 runtimes first. Well one more glitch: you can't use ActiveX EXEs this way, they still require registration.
My advice is this. Try to keep the installer as simple as possible. Windows Installer is a very complicated piece of software and when things don't work right it can be hard to figure out what's going on. I'm sure we have all experienced the endless loop of Windows Installer trying to repair a file that you no longer have the source .msi file for.
Most of the time using Windows Installer is like using a sledge hammer to crack a nut.
I use InnoSetup for my own stuff and InstallShield at work (against my will). Start with a simple script based installer and only use Windows Installer if you have a good reason to.
Note that support for installing assemblies to the GAC may be missing for some non Windows Installer setup tools (such as InnoSetup).
I used to LOVE Inno Setup. Emphasis on "used to".
When you run the single file installer (what you'd typically do), it unpacks the real setup program into a folder under the temp folder and then tries to execute it. The problem is... some anti-virus programs don't allow this.
The author is aware of this and refuses to do anything about it. The folder name is random, so cannot be added to any exemption list your anti-virus program may use.
Again. The author is aware of this and suggests that I tell my users to turn off their anti-virus programs during installation. (Like that's going to happen)