The mentioned version of the TeeChart was released at the End of January 2013. The included TeeChart.dll has version (e.g. the .net40 one): 4.1.2012.1312. Unfortunately this version is smaller than all previous version of the TeeChart released in 2012. Actually the version should be 4.1.2013.1312, but it is not. Because of the version mismatch the WindowsInstaller is not able to upgrade this library. It uninstalls the previous one, but doesn't install this one, because its version is older as e.g. 4.1.2012.2283.
So does anybody (specially Steema guys are asked here) has any idea how I'm supposed to distribute that by a normal Visual Studio vdproj setup???
What I'm currently doing is: I modify the 'File' table within the MSI file and set the value of the 'Version' column for the TeeChart to the correct version and it works. Unfortunately this version is the last one, which my license includes, so I'm not able to skip it and move to any of the following versions of 2013 without buying a new license.
First of all, bear in mind that *.vdproj projects are a deprecated Microsoft technology as you can read here:
The Visual Studio setup projects will not ship again – VS 2010 was the
last release with support for it. So, you’ll want to make plans to
migrate to something else.
Having that in mind I can think of the following options:
That's an unfortunate coincidence. However, if you stick with *.vdproj, you might need to upgrade your TeeChart subscription to get an up to date assembly.
Alternatively, you can use a workaround similar to what 0xA3’s answer here.
Considering that *.vdproj is an obsolete technology and given OxA3's answer, you could upgrade your installer builder toll as suggested in Christopher Painter's comment:
I've been down that road with VDPROJ and in no time you'll hav dozens
of these postbuild scripts to get around the fact that VDPROJ sucks.
Dump VDPROJ now for another tool (WiX or IS 2010 LE ) and you'll have
a longer life. :-)
Related
I have experienced the famous error 1001 today. The reason for this, was apparently that the .NET Framework File Locations for InstallShield LE were changed to the path of .NET 4.0 even though the project is just using .Net 3.5 .
Does anyone know why this setting was changed? I am suspecting that a Windows Update for the .NET Framework might have caused this.
It took quite some time to figure this out, so I would like know what the actual cause was and how I can prevent it from happening again.
For those of you who should stumble upon this and have the same problem, it can be easily fixed (tested in Visual Studio 2012 and InstallShield LE). Run Visual Studio as admin and go to the InstallShield LE tab. Select "Options" and go to the ".NET" tab. Now select the correct path for your .NET Framework according to the version you use in your project.
You said it yourself, the (in)famous 1001 error. Do yourself a favor and switch to WiX ToolSet's Deployment Tools Foundation (DTF) managed custom actions. You can encapsulate this in a WiX merge module project and then consume the merge module in your InstallShield LE project. It's such a better design pattern.
One of the really nice things about DTF is you can compile a custom action for .NET 2.0 and include a CustomAction.Config that allows it to bind to CLR 2.0 or 4.0. This makes it practically bulletproof from XP to Windows 10.
Aren't your users important enough to make sure they never see a 1001 error? Isn't your help desk important enough to make sure they don't get those calls? Isn't your brand important enough to make sure that users don't post your product sucks on social media?
Every where I look Quick Info in Visual C# looks something like this:
Yet my Quick Info box only shows the name/declaration, without any description.
Are longer descriptions cut from the C# Express version? Or am I doing something wrong? XML comments I'm making work as intended, if it helps.
It depends on the specific framework target and type you selected. But for a 4.5 desktop app, this information comes from an .xml file, C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\mscorlib.xml. The relevant part of that file is:
<member name="T:System.DateTime">
<summary>Represents an instant in time, typically expressed as a date and time of day. </summary>
<filterpriority>1</filterpriority>
</member>
So check if that file is there.
Thank you alex and thank you Hans. Both of your answers lead me to my solution. Also thank you for as quickly answering as you did.
The Road to Solution (might be useful for some, if not skip to The Solution).
The file Hans mentioned did exist. Also it did for version 4.0. I also tried to install documentation for Visual Express (as per alex's tip) only to find out that Visual Express 2012 installer doesn't have any options during installation (at least not that kind).
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework also contained v3.5 folder, but there was only a Profile folder and no mscorlib.xml (or other files that v4.5 and v4.0 had).
Realization came when I found out that Unity3d uses Mono equivalent of .Net 3.5 and in the project setting I found that it was setup for .Net 3.5 (if any one is wondering - Visual Studio is used only for coding, Unity compiles everything).
Few hours of searching later I did find the "documentation" for .Net 3.5.
The Solution
What is needed is Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1. The only thing required to check during installation is Developer Tool->Windows Development Tools->.NET Development Tools. All the Quick Infos for C# functions in my project are now showing correctly!
A note: I tried to find mscorlib.xml for .Net 3.5 afterward but no luck, so I don't know where or in what format the XML documentation for .Net 3.5 is kept but I'm happy as long as it works.
More likely, the documentation is cut from the express version to reduce the download size. Have you installed documentation with the visual C#?
my team have built many tools for our project using win forms and Visual Studio 2005. We are thinking about upgrading to VS 2010.
Just wanted a heads up on any compatibility issues and also any benefits of upgrading.
Does upgrading involve lot of time and effort or does Visual Studio take care of it?
Your answers will be help us take a decision. Thanks.
Pros:
.NET improvements (provided that you upgrade the framework version)
Availability of newer 3rd-party libraries and tools for newer .NET (same as above)
IDE improvements
Neutral:
WinForms hasn't changed much between .NET 2.0 and 4.0.
Cons:
VS 2010 is a vastly heavier program, requiring much more CPU and RAM and faster disks to operate smoothly.
You decide.
as far as I know are there no downside's
I only know that all your changes in the visual side are gonna be placed in [name of form or usercontrol].Designer.[cs/vb]
I am a user of VS2010 and Im really happy with it so,
but why not wait on VS2012?
Kind Regards,
Corné
Yes it is possible and easy but lot of depends on the features you have used in your app. It should not be depreciated in VS 2010. Take a back up of your project and try to convert it, conversion wizard will list out all the warnings and error it faced while converting your app.Then you can take a decision on the basis of it whether to upgrade your app or not?
You'll want to check the breaking changes in C# 2008 and C# 2010, then the migration issues in .NET 3.5 and .NET 4.0, but only if you choose to upgrade the Framework target. Simply upgrading it to be readable and compilable by VS 2010 should not introduce any major issues. But, check if your project involve external component that's upgraded/removed in VS 2010, such as Reporting components, SQL connection, etc. In my experience, third party component suffer the most.
As for the benefit, lots. Check the Visual Studio Gallery for some extremely useful extensions (my favourite is the free Coderush Xpress), experience the joy of C# REPL with Roslyn, or heck, simply the Intellisense improvements makes me dread every time I'm forced to use 2008 or other IDEs.
Open the VS2005 solution in VS2010 and a wizard will open and upgrade your solution.
Just take a backup on the existing solution and give it a try. VS 2010 is very nice!
Everyone has different expectations and differences in their list of pros and cons. As such, the best way to decide if it's right for you is to go ahead and try it. As already mentioned, it will upgrade your project files (including making a backup for you first) when you try to open them.
You can download the trial from the Microsoft website and install it alongside your existing VS2005 install. If you're worried about installing alongside, install it into a virtual machine or download the ready made virtual machine images from http://blogs.msdn.com/b/briankel/archive/2010/06/25/now-available-visual-studio-2010-rtm-virtual-machine-with-sample-data-and-hands-on-labs.aspx
So on my computer I only have Visual Studio 2010 Express. I need to edit a Visual Studio 2008 project, however it needs to be kept in C# 3.5.
Before I open it in 2010 and accidentally upgrade it, will it be kept in 2008 or C#3.5 format?
I realize I wont be able to use .Net 2010 features, so thats no problem. I just want to make sure if I save my 2008 project using 2010 I will still be able to open it in 2008 and it will work fine.
The target framework of the project is independent of the solution format. That is, you can convert your project to Visual Studio 2010 and still target the 3.5 Framework. But, once it's converted to 2010, you will not be able to open it in 2008.
You cannot open a project in VS2010 without it being upgraded. The Framework version can be controlled independently, so you can still target 3.5.
The changes to the project/solution files to use 2010 (assuming you don't use any newer features) are fairly minimal, so there may be mileage in just not committing the project/solution files (you can probably achieve this by dropping an ignore file for your source control provider in your local folder, including adding the ignore file to itself, so that doesn't get committed).
If you're mostly editing code (and not often changing the projects in the solution, or files in the projects) you could also have two copies of the files, one for each version, until you can commit to 2010 everywhere (and with Express for free, you might be able to do this quickly?).
No, VS2010 will convert the VS2008 project file. After it is converted, VS2008 can no longer open it. There are ways to hack around this, the simple solution is to just use VS2010 consistently. Next best thing is to only check-in the source code changes. Next best thing is to give the 2010 project a different name and maintain them both, at least for now.
You'd be hard pressed to accidentally upgrade it. When you open a VS2008 project in VS2010, it automatically starts the upgrade wizard, and you have to decide whether to let it do the upgrade, including making a decision whether to let it take a backup before it does the upgrade.
You can't open a VS2008 project in VS2010 and work on it without upgrading it to VS2010 format first. And once you've allowed VS2010 to upgrade it, you won't be able to open it in VS2008 any more.
Careful though - don't confuse the version of the framework you want to target, with the version of VS that you're using.
You can target framework 3.5 with VS2010.
There are hacks that let you open VS2010-upgraded projects in VS2008, but it's not a great plan to go down that road (guess how I know).
When you are going to convert it with compatible to 2010 it will ask for the backup...
so... later you can retrieve your file back ...
I might be wrong but I'm almost sure that project files don't differ between 2008 and 2010 or at least they are compatible. Solution files are a different matter and old solutions do indeed need to be converted. Usually you have few solutions for 2008 and 2010 versions of VS, but they contain the same projects, so the projects don't need to be converted.
I was on a seminar where they took this (short of classic?) accident as a sample for versioning. They get a 2008 project from git and start it in vs 2010.
Did the upgrade process and then "ops, i can't revert the upgrade". They commited the vs2010 converted files to a branch in GIT. When they "came home again", merged the changes in project together with 2008 solution files.
This may not come in touch to you, but the sense is:
All files is intact but the solution/project files. So just keep them safe and you can continue use the 2008 version after done your editing in 2010.
Though, without any kind of manual handling of solution/project files - answer (on the question in your subject) is No!
In short, no. Once it's upgraded, it stays that way. There is no official way to downgrade it either. The main driver behind this fact is because of the compiler. Even if you stay in .NET Framework 3.5, you can still use C# 4.0 features (like optional / named parameters) since 2010 will always use the 4.0 compiler.
Imagine a situation where it stayed in a 2008 format but you used a C# 4.0 language feature. Since VS 2008 always uses the C# 3.0 compiler, whenever you open it in 2008, it will no longer compile. This is a good reason to avoid work-arounds that have been posted for downgrading - you get mixed compiler features that can break things pretty easily.
When I try to install the Async CTP for Visual Studio 2010 the installer fails.
I got the same problem bob mujica described in http://social.msdn.microsoft.com/Forums/en-US/netfxsetup/thread/2b816f97-ba1a-4342-824f-07c53f946b57.
Now Visual Studio doesn't work at all. I don't care about having CTP, I just want Visual Studio back. Does anyone know how I can do this?
Ian,
I know it won't help in this scenario but a little advice for the future that could save a lot of heartache. for the past 7-8 years, i've got into a disciplined habit of making a fresh backup (ghost) of my program partition (genarally the c:\ drive in my case) everytime i add a new program feature (other than service packs etc) to my installation. This basically means that should something 'not work' after installing, I can simply restore the ghost image over the top, rather than spend hours trying to figure why.
As i said, may not help this time but is a good discipline to work towards in the future.
My recommendation would be to install a fresh copy of Visual Studio, or perhaps to copy files from a fresh installation to overwrite any updated libraries. Assuming that you have the installation media you could also try to repair the installation from Control Panel -> Programs (Add/Remove Programs if you're still on XP).
From the linked post it sounds like either (a) a library file has been overwritten with an incompatible version or (b) a library file is referenced but not found on the system. (a) likely can be fixed by trying any of the above. (b) most likely requires VS to be removed and reinstalled from scratch. If you have a second machine around, you could try installing VS on that and dump or record the relevant registry changes and compare it with the faulty installation, but it might be faster just to reinstall.