Why is the J# redistributable package 1.1 mandatory when installing Visual Studio .NET 2003?

I was looking at some blog items that were posted about Microsoft products last night, and I stumbled upon this one on Michael Teper's blog.  The question he raised is one that I've run into a lot within Microsoft, particularly from C++ developers that have to install Visual Studio .NET 2003 to do their day-to-day coding work - why do I have to install the Visual J# redistributable package 1.1 before I can starting installing VS, even if I'm not going to be doing any J# coding?  (of course, in the mails from internal devs I have to remove the expletives from the question also.....  🙂  )

Since I was on the VS setup team at the time that we added J# to the suite of tools/languages and I know why this is the case, I thought I would try to explain this design.  It helps to start by looking at the background and planning of the VS 2003 product.  When VS 2002 finally shipped it was nearly 4 years after VS6 had been released, and we wanted to make sure that the next release of VS was not going to require 4 more years of bake time, partially because a lot of customers will wait for Microsoft to release a service pack or 2 before they will jump in and start using a v1.0 product (which is essentially what VS 2002 was in comparison to VS6, and it is exactly what the .NET Framework 1.0 was).  So, VS 2003 was originally planned to be a 6-month project that would essentially be a 1.1 release for VS 2002 and would contain only bug fixes to existing features.  The only new features would be the new J# programming language and smart device project support in the IDE for C# and VB .NET.  In fact, some of the early plans for VS 2003 had proposed to ship it as a service pack that would install on top of VS 2002.

Anyway, with the mandate that we would be shipping in 6 months, the setup team planned very limited work for VS 2003 - some deployment improvements for the .NET Framework redist package, the OCM package that would be used to deliver the .NET Framework 1.1 to Windows Server 2003, and the addition of the J# language tools and J# redistributable package that was required for J# applications to work correctly.  We considered putting the J# redist functionality into the .NET Framework 1.1, but rejected that for several reasons.  Then we considered including it in the main VS setup tree, but also rejected that because it is needed at runtime in addition to design time and we couldn't tell people to install a part of VS on their clients' machines in order to enable J# applications to work correctly.  We also tried to propose that the J# redist installation package be installed if the user chooses the J# programming language in the VS tree, and then the IDE could install it on demand or provide UI to guide the user to install it themselves if they really needed it.  This presented usability issues, caused an additional barrier to entry for J#, and also caused problems with administrative deployment scenarios where the end user was not an administrator when they were using the IDE and could therefore not install products themselves.

That left us with the option of including it as a distinct component in the Visual Studio Windows Component Update (renamed to be Visual Studio Prerequisites in VS 2003).  The obvious drawbacks of this decision are that people who don't intend to ever develop a J# application are forced to install something they do not need, and worse yet, are blocked from installing Visual Studio if this thing they don't need fails to install.  In an ideal world with infinite time and resources, we would have added logic to our setup to be able to associate a component in the VS Prerequisites part of setup with the features in the main VS feature tree.  Given a 6 month milestone, that was not feasible because it is non-trivial to artificially introduce a feature-level dependency within one MSI on a component that is not also in that MSI, and we did not support nested MSIs.

As we now know, the VS 2003 product cycle extended from the original 6 month target to something like 15 months (in order to better incorporate customer feedback we started getting for VS 2002 as well as to increase the overall quality and stability of the product we wanted to ship).  By the time that became evident, we had already passed the window of opportunity for coding up a new bit of dependency logic to give a better experience for installing the J# redist.  Unfortunately we have heard lots of feedback since then from customers and also from Microsoft developers who only want to install VS to code in C++ and don't want anything J# related, etc.  The good news is that this type of setup logic is now in place and will start being used in the VS 2005 beta2 timeframe.

In the meantime, I can offer a couple of workarounds for folks who don't want the J# redist on their machine:

  • Prior to running VS 2003 setup, you can manually install the other items that normally get installed by the VS Prerequisites.  They are all found in sub-folders on the VS Prerequisites CD.  Then you can insert the VS 2003 CD1 and browse to the Setup subfolder.  From there, run setup.exe NO_BSLN_CHECK to allow you to install VS while skipping the enforcement of installing the J# redist
  • If you have already installed VS 2003, you can go to the add/remove programs control panel and uninstall the J# redistributable package 1.1 without any harm being done to your VS installation (unless of course you are using the J# programming language for windows or web application development in the IDE)

Hopefully this gives some insight into how Visual Studio .NET 2003 setup behavior came to be and what we're doing about it in the future.  Let me know if you have any comments, concerns or follow-up questions....


Comments (17)
  1. Nicholas Allen says:

    I’d recommend some caution before doing this. I tried uninstalling the J# redist a few months ago from VS 2003. After doing that, VS refused to start up again until I did a repair (which just put the redist back).

  2. Don says:

    By an amazing coincidence, I have a VS2003 installer running on my desktop as your posting went up on blogs.msdn.com.

    The coincidence gets even weirder because the installation is hanging at the end of installing the Visual J# .NET Redistributable Package. Progress bar has been at 100% for about 5 minutes.

    Any hints beyond the NO_BSLN_CHECK? I initially tried to do the installation via remotedesktop, which worked fine for the first couple prereqs but caused an error with Visual J#. Now every time I try to run the install it hangs at the end of the Visual J# installation.


  3. Aaron Stebner says:

    If you can go to %temp% on your machine and find the file named jsredistmsi.log, then zip it and email to me at aaronste@microsoft.com I will take a look and see what I can figure out. Sorry you are having trouble getting VS installed 🙁

  4. Aaron Stebner says:

    Also – to respond to the first comment, that is something I haven’t seen before. I know that if you uninstall the .NET Framework redist the Visual Studio IDE will fail to launch, but I haven’t heard of that yet with the J# redist package.

  5. Don says:

    Why wouldn’t VS2003.NET install for me? At long last, as a result of some great detective work on Aaron’s part, we have the answer.

    Somehow, I ended up with a bad firewall configuration that was preventing the Microsoft Management Console from communicating with IIS (I’d noticed that I couldn’t configure IIS this morning, but had put the issue on the "deal with it later" stack).

    Aaron discovered that the J# redist install was hanging in a recursive function that was trying to communicate with IIS, which led me to dive into why mmc.exe wasn’t opening. Once I blew away an assortment of application-specific firewall settings in Norton Internet Security (more on a hunch than based on any sound leads), all of a sudden J# was installing properly.

    I’m happy to report that VS2003.NET is now busily installing itself on my machine. I doubt if anyone else will ever be faced with this particular nightmare, but just in case they do – the solution is "on the web, just google for it" 🙂


  6. Aaron Stebner says:

    Quick update – last night I installed a daily beta2 build of Visual Studio 2005 and I am happy to report that when I unchecked Visual J# and Visual Web Developer that I was not required to install the J# redistributable. So the issue described in this blog item will be a thing of the past in the near future!

  7. Why You Need J# To Install VS.NET

  8. Now that Visual Studio 2005 beta 2 has been released, I have gotten a handful of questions about my blog…

  9. Even when I uncheck J#, the J# 2.0 redistributable is still installed with VS 2005 Pro. Moreover, the package has now grown from around 14 MB to over 100 MB. Why are we forced to install this?

    When I uninstall the redistributable pack separately from add/remove programs, VS 2005 locks up and needs to be killed from task manager. This is unbelievable.

  10. Hi Thomas – I posted a couple of follow-up items about the J# redist package and VS 2005 setup that help explain why you may still see it installed if you uncheck J# in the VS 2005 Pro setup UI:



    Most likely, you still have Visual Web Developer checked for installation, and that is pulling in the J# redist.

    I’m a little concerned about your statement about the size of this package though.  I looked at the compressed J# redist package, and it is 3.7 megabytes, and I don’t have exact data but I believe that the footprint when you install it should be less than 20 megabytes.  If you are seeing differently I would like to know more about where you are getting that data.

  11. Thomas McLeod says:


    Thanks for explaining the situation with the J# redistributable and VS 2005. However, this information should be in the readme file. With J# language unchecked, it appears as if the J# redistributable installation is an error, bug or some other kind anomaly.

    I said over 100 MB because Add/Remove Programs lists the size of the J# 2.0 Redistributable as 141 MB.

  12. Hi Thomas – I am not sure why this scenario was not described in the readme, but I would guess that the team decided that it would not affect enough scenarios to warrant that much of a write-up.

    The size listed in Add/Remove Programs is not a reliable indicator of the installed size of a program on your computer.  If you are interested, Raymond Chen wrote about this topic in his blog at http://blogs.msdn.com/oldnewthing/archive/2004/07/09/178342.aspx.

  13. Osama Abbas says:

    Ever since I started using VS 2003, one thing that always ticked me off was why the J# redistributable

Comments are closed.

Skip to main content