What is the future of Windows Script Host ?
Microsoft has announced, in may 2015, the end of VBscript and ActiveX in their new browser Windows Edge (and that's a good news for web standards, by the way). However, I can't find out recent information about the desktop part of the scripting world. I'd like to know if VBscript, wscript.exe, cscript.exe and mshta.exe will still be supported by the next Windows desktop versions. I'm worried because Windows Script Host reference is, days after days, more and more difficult to find in MSDN library.
I've a lot of vbscript and hta files to maintain (in a professional environment) and I need to anticipate if a migration will soon be required.
If you have any information about that, please share !
It is on sustained maintenance so no updates (unless a major security flaw is found).
Millions of businesses use so it is safe for admin purposes. Well over half of all programmers are basic programmers.
Yes, this question still stays relevant nowadays. I also can't find any official announcement from Microsoft. They ended up with IE and AHT support years ago, but WSH stays usable. So, the answer is: there's no official end date for it, but Microsoft stimulates programmers to choose Powershell over VBScript for new applications.
Having tons of professional VBScript code running and with Powershell's leaking for easy Windows deploying and maintenance in mind, my piece of advice for you is: stuck with VBScript until you can develop a custom flawless deploying architecture for Powershell. Then, start every new project with the last, but keep the support for the former until its app's end cycle comes.
Since the above-mentioned exe files are part of both the already released Windows 11 and Windows 12 in the test state, it can be rightly assumed that sooner or later Microsoft will further develop both VBScript and the closely related HTA. Last year I read in a Microsoft blog post about Windows that the company is already working on enabling VBScript to be able to use .NET classes directly, and on updating mshta.exe, that in Windows 12 the new version can be released.
Since I myself do VBScript-HTA developments, I was also concerned about how long the company would support this. But after reading this blog post, which unfortunately I can't find now, I am no longer concerned with switching to other systems.
The fact that Microsoft has further plans for the VBScript-HTA pair is perhaps also indicated by the fact that one of the example programs of the new Visual Studio, VS 2022, which has just been released, demonstrates how to integrate a new language into the VS environment through VBScript. And also trough it is demostrated how to develop a new project template.
Related
I have been trying to begin development for a 'Datalogic Falcon x3+' device, and have had no luck so far even getting started.
The device currently has Windows 2006 C.E installed, and it has the most up-to-date firmware possible.
After doing research I found very little information on this device - specifically to develop for it, and all I have found is from the official website some old documentation and the SDK, which requires Visual Studio 2008. I could only find Visual Studio 2008 Express, and had no luck using the SDK.
I found a few posts relating to this device on SO, however there were no details pertaining to my line of questioning.
Does anybody know how to develop for this device? Is there perhaps any other IDE's I could use, or does anyone know how to perhaps make a simple application without use of the SDK?
You don't state clearly what kind of "development" you want to do. But a scanner is really just a replacement for a keyboard. That is, it scans a barcode and decodes it into a text string, then delivers the string <somewhere>. That text string could just as well have been hand entered by someone using a keyboard; the scanner just does it much more quickly and accurately.
So one solution, given in another stackoverflow topic, is to create a simple web form with a single input field to receive scanned data, then process the data on the back end (web server) with a PHP program, or any other CGI program of your choice.
We have developed a .Net 4.0 VSTO Excel AddIn in VS2010 that we are deploying via ClickOnce. Our deployable seems fine on Windows XP but is extremely problematic when installed on Windows 7. The problems all seem to relate to when the AddIn needs to be removed via Excel (i.e. it has been soft deleted by Excel [eg. due to failure, etc] and it is then 'Remove'd by the user via the Excel | Options | AddIns | Manage | COM AddIns dialog.
The above leads to a situation where an AddIn is re-installed after the above has occurred, it is not exposed within Excel - i.e. the Excel AddIns tab (which would normally appear if there is one or more AddIns installed) vanishes forever. It becomes even more of a problem when we are developing/debugging, as we are renaming/removing AddIn instances on the fly - so much so that developing VSTO on Windows 7 is no longer feasible
Note that the AddIn is not in the hard deleted (disabled) list - it has been removed. I have tried installing/re-installing/uninstalling, rebooting, removing registry items (cleaning up cache/after-uninstall), removing file system files from C:\Documents and Settings\\Local Settings\Apps\2.0, clearing cache (via mage and/or rundll32 as per Clear the .NET-downloaded application cache without Mage?). There seems to be a clear difference of behaviour between XP and Windows 7.
Has anyone had similar problems ?
The only alternative I can see is a deployment project with a fully blown MSI, however this is no where near as neat - requires local Admin access, etc
Many thanks
Travis
Not sure if you have read about the tutorials about publishing Office solution using Clickonce. If you haven't, you can find them via the links below. Worth reading.
http://msdn.microsoft.com/en-us/library/vstudio/bb772100(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/vstudio/bb608591(v=vs.100).aspx
Regarding using windows installer, it's not extremely hard to do, especially with Visual Studio 2010 setup project. Here's a very detailed tutorial that can guide you through all these. It helped me a lot when I was trying to deploy the Excel add-in, and I hope it'd help you too in some way.
http://msdn.microsoft.com/en-us/library/ff937654.aspx
Also you might want to ask yourself these questions to determine whether or not using Clickonce/Windows installer is the right choice.
When it comes to your choice in deployment technologies, you don't
need to limit yourself to just one option. The key is to choose the
right tool for the right job. While there is no single rule or simple
answer, there are some general guidelines you can use to help make the
best decision for your specific needs.
Does the application install any COM components?
Does the application require registering any components for COM-Interop?
Does the application install any services? Does the application have to
install to a specific location or to the Global Assembly Cache (GAC)?
Does the application have any components that are conditionally
installed, based on the operating system or runtime environment?
Does the application require user input at installation time?
Does the application require configuration of system-level services such as
Active Directory or COM+?
After the application is installed, does it create files, write to the
registry, or affect the system in some way that would leave resources behind when the application is removed?
If you answered yes to any of
these questions, then Windows Installer is the best choice for
your needs. However, if you don't need to address the scenarios
described in the list above, then ClickOnce is an excellent candidate
for your deployment solution. If you want to leverage the distinct
benefits provided by ClickOnce, then understanding the capabilities of
ClickOnce early in your application design process is critical.
Deploying an early version of an application with ClickOnce, but then
belatedly realizing a need to move to Windows Installer, would create
a difficult upgrade path that can be avoided through careful up-front
planning.
From my experience, on one of my production projects we have also used MSI. And problems with click once were avoided. So my answer - yes you need to have MSI Project or MSI installations. And with MSI installations you can either use default MSI Project or external, e.g. Wix or Wise Installer or something else. Second way with custom installer is much more harder.
For situations with removing I've used mage and manual delete add-in from cache and registry. It helps, but looks like hacks.
Also each time when dealing with VSTO ClickOnce unclear, I've thought to use some external libraries. Unfortunately I haven't such opportunity to use something 3rd party to make my work easier due to requirement to project. But you can check and try. May be Add-in-Express libraries will help you, especially when they have good technical support.
What we found was that the way to get ClickOnce working for VSTO on Windows 7 was to do this within Excel - i.e.
Add/Remove Programs : uninstall
Excel | Options | AddIns | COM | Go
Add | browse to the ClickOnce setup.exe | OK | etc
Close down Excel
Go into Excel
AddIn appears
I'm sure you can play with the Add/Remove programs uninstall (versioning) so the user doesn't necessarily have to manually uninstall
ClickOnce is gr8 when it works - it's journey to get there tho and needs to be tightened up big style
I would like to know if you could share some (trusted) sources of information (books, URLs) that you consider the most relevant for learning Windows Installer. They could be for starting on this technology or for an advanced or professional level of knowledge.
Where can a future deployment engineer start and where can he/she go to keep on the right direction (step by step)?
I'm obviously biased but I think my blog and the WiX toolset are good ways to learn:
http://robmensching.com/blog
http://wix.sf.net (click on the Manual or Tutorial links on the right)
Some people like Phil Wilson's "The Definitive Guide to Windows Installer" but I never read it. I learned straight out of the MSI SDK.
I did 7 years of writing InstallScript installers before ever picking up MSI. While there is a huge difference between procedural script-driven imperative installs and data driven declarative installs, they both do the same fundemental thing: deploy software.
I became an MSI Expert but studying everything I could on the domain, writing LOTS of installs and by blogging for 7 years and answering over 4,400 posts on the InstallShield community forums. The only way to go in my book is to have been there and done that.
So the first step in your quest should be to understand the Windows Platform and related technologies very thoroughly. These evolve over the years but you should get a decent understanding of:
Fundamentals
Registry
FileSystem
NTFS
ACL's
DLL Types ( Win32, COM, .NET Assembly)
Win32 API
.NET Base Class Libraries
Service Control Manager Drivers ODBC
SQL IIS Active Directory ( GPO, LDAPand so on )
Global Assembly Cache
WinSxS Cache
DLL Hell
Good and Bad Installer Behavior
The second step is
Tools
Now let's start to writing installs. As Leslie ( Easter I assume ) said in another answer, pick a tool and learn how to use it to accomplish the above things. But don't stop there, as soon as you can go to the next step.
MSI
Start digging deep down into how your tool is working behind the scenes as soon as you can. Just as you can write C# in .NET and look at the IL with ILDASM, learn to use ORCA and see what is happening. Read the MSI SDK. Yes, it's rough and cryptic but I spent 3 months commuting beween DC and TX and I spent at least 16 hours a week traveling away from internet connections but nothing except the SDK to read. Read it, know it, live it... the cryptic help topics will eventually start to click and become second nature.
And finally, read my blog: DeploymentEngineering.com and every other blog you can find.
There is not a simple answer. The primary reason is that most install developers use a specific tool which in turn hides the bulk of Windows Installer behavior. While it would be nice if those developers had an in-depth knowledge of Windows Installer, that's not the case.
My suggestion would be as follows:
Focus on a specific tool. Many of the development environments offer a trial period and some are free. The on-line help for these tools plus the act of building some sample packages will be a useful process.
If practical, consider taking a training class for the tool. I know Flexera sells their basic and advanced InstallShield course manuals. They are a bit over-priced, but it does include need-to-know Windows Installer specifics. The problem you'll run into is that most documentation is specific to the tool without explaining a lot of the connectivity to Windows Installer.
You'll need the Windows Installer SDK -- in addition to the help file, there are some interesting tools and VBScript scripts. Orca is one tool that is included with the SDK and there are similar tools on the Internet (SuperOrca, InstEd, etc.). The SDK is not a great read but it is a great reference. As you come across specific questions regarding Windows Installer use the SDK help file to understand the deeper internals.
Google 'windows installer blog'. You probably don't want to hear that, but there are many great blogs available that cover many bits and pieces of Windows Installer. Make sure you pick up the Windows Installer Team blog.
No matter what path you choose, you'll find learning Windows Installer to be a hands-on process. I hope this helps!
I'm also biased, but this might be helpful. I recently revisited WiX for a real-world Windows Installer project and wrote up my solution which ultimately plugged into a continuous integration server.
The steps in the article take you through using WiX, localizing the MSI, and creating a bootstrapper for installing any prerequisites.
For learning, Tramontana's tutorial WiX helped me a lot.
A nice little blog post about how to debug custom actions is WiX and DTF: Debug a Managed Custom Action and how to generate an MSI log.
I have been using Visual Basic 5 since it was first released until a couple of years ago.
I re-installed it on each new laptop I bought and downloaded the service pack each time. I think it is SP2 for VB5 I need.
But having not touched it in two years I have now just installed it on a laptop to modify an app. However, it seems that Microsoft no longer offers the service pack for download.
And on opening my projects i get repeated messages for each frame telling me I "don't have the license to use the control in developer mode".
What is this error and how do I get the service packs?
If you port to VB6, you shouldn't have to make very many changes.
If you port to any version of VB.Net, you will find that the changes are rather extreme. An automated tool will try to do some of the work for you, but depending on how your code was written and what VB5 features you used, you will probably find that you manually need to fix up most of the changes that were made.
The biggest problem is that some of the VB5 features don't have direct equivalents in VB.Net. Do any of your forms use control arrays? You CAN do something at least vaguely similar in VB.Net, but the conversion tool doesn't know about that, so converting them will have to be completely manual.
FYI, Microsoft service packs are available in two forms. The normal update process figures out what patches are needed on your computer, then downloads them and installs them. But there's also an "administrative" version that downloads every change that MIGHT be needed, in one package. That package doesn't automatically install - when the download is complete, you have to manually start it running. The admin version is intended for system administrators, who might have to apply the same patch to dozens / hundreds / thousands of computers on a network - you shouldn't have to download the same data over and over.
The admin service packs won't help you with VB5, of course (unless you find someone that downloaded the VB5 service packs and held on to them). But if you end up going to a new version of Visual Studio (or VB), and you think that it's likely that you'll keep using them more than 6 months or so past the end of Microsoft support, you might want to get in the habit of downloading the admin service packs and archiving them somewhere. It might prevent problems like this in the future.
The licensing issue is referenced on Microsoft knowledge base
http://support.microsoft.com/kb/181854
A fix is available, downloadable from the same place.
Note : if you are running Windows Seven, you need to run VisualBasic in elevated mode.
I produce server software and have been fine with all Linux environments so far, both for production and as deployment target. However, I want to provide a broader choice of target environments in the future and I'm also planning features that would consume and produce Office documents.
As a first step, I am looking for a good way to get a number of MS software products (XP, Vista, Server 2003 & 2008, Office 2000, 2003 & 2007 ...) to put on some VMs in my testing setup, so I can start to play around.
So far, I get quite a good impression from what I read about MS's partner program (aka Action Pack). The only thing I'm missing from what the website tells me is older software versions. As I want to mimick possible customers' setups and there's always a lot of people that run older versions, that would be quite important for the testing scenario.
Eventually, I'm going to face similar questions with Apple OS X, so if anybody has some hints on that, I'd be glad, too.
I really think that you are looking for an MSDN subscription, with an MSDN subscription you get access to the older software and can use for development/testing.
I would read up on the details from the MSDN site. They list the OS versions and items you can get with each.
As a Microsoft Certified Partner you can access the MSDN Subscriber downloads. There you will find all (?) versions of windows back to 3.1 and most versions of office (back to office 95, but excluding Office 2000).
The licenses allow you to use the software for development, but not for production use, so you should be fine with it.