Is there a way to make VS2008 work with the old (vs2005 crystal reports) assemblies and not require any updates to be installed in the client machines?
We have upgraded a Visual Studio 2005 .net 2.0 solution to Visual Studio 2008. The purpose is to take advantage of the IDE improvements and because it supports multi targeting. The solution still has to be built against .net 2.0.
It all works as advertised, we rebuild and run it in a machine with only .net 2.0 installed. But during testing we get an exception when we try to show a Crystal Report that is included with the application.
Then upon review we find out that without telling us, Visual Studio changed the references to the crystal assemblies and pointed our solution to the updated versions that come with vs2008, which requires crystal runtime be updated on client machines.
We did try removing the references and adding the old ones but it won't compile.
don't use Crystal reports
You could try to put all reports in a separate project. Then create a second visual studio solution in VS2005 which uses the same project (add existing project).
Then use VS2005 for editing your reports. Create a library directory for your references in vs2008 and reference the vs2005 dll's.
Don't know for sure if it works, but it could be worth a try.
We tried this and ultimately just ended up upgrading all of our machines internally to the latest and (not so) greatest.
I would just bite the bullet and upgrade. I've found some performance improvements in the Crystal Reports 2008 for some data intensive reports.
We ran into the same problem. You can have the project reference the old DLLS, which works but can lead to DLL hell. Having fought that kind of battle before, I can't recommend it.
After exploring the Crystal Reports site for a long time, I came to the conclusion that there is no good way to solve this problem short of upgrading to Crystal Reports 2008 or switching to a different reporting engine.
In our case, we had not yet developed a large number of Crytal Reports, and our reporting needs are modest. We switched to the Microsoft Reporting Technology that is bundled into Visual Studio. It took a bit of effort to figure out, but so far it looks like it will do anything we will ever need. Not upgrading Crystal Reports saved us a non-trivial amount of money.
Hope this helps.
don't use Crystal reports
You could try to put all reports in a separate project. Then create a second visual studio solution in VS2005 which uses the same project (add existing project). Then use VS2005 for editing your reports. Create a library directory for your references in vs2008 and reference the vs2005 dll's.
Don't know for sure if it works, but it could be worth a try.
Related
I ran Dependency Walker on an assembly (.exe) after compiling in Debug (Any CPU) and it seems like there are older core and kernel issues. The entire code is VB.NET 2010, so I am wondering why VS2017 Pro didn't clean those out?
Something interesting was that the Conversion to a new VS version did not occur, for which errors are shown -- it just showed the forms, modules, etc. as if there were no errors.
Should I try a Reload or something?
The errors were caused by having old references or assembly libraries which called DLLs (like VBIDE.dll and MSCORE.DLL) in the applications folder. There were very old references, some of which were to VB6.
Recall, remember that Visual Studio has always been dropping certain Windows forms controls over VB 2005, VB 2008, VB2010, etc. so you need to make sure those older controls are not in forms when you upgrade to e.g. VS 2017.
I have no idea/experience in VB programming. One of my client bought me his old project which need to be modified. He says it is written in Visual Basic and no idea which version.
So how can i carry ON to work with this project by identifying the version
And what other components do i require to do the programming and user interface.
I already have Visual studio 2010 with me. So can i do my work using this software or i have to go for anything else...
Any suggestions....?
Regards
ParshTest
You need to check the earlier VS version. If the project was developed in earlier version of VS, you can upgrade to VS 2010 easily but otherwise you need to get hands on specific VS version.
Similarly if the project have database functionality or crystal report or any other external dependencies, you need to check their versions. You need to install the components according to these versions. Specify your versions and i'll tell you what to use for further development.
I have an existing Visual Studio 2005 project for which I get a conversion wizard prompt when opening in the freshly installed Visual Studio 2010. What are the implications of carrying out this conversion? Converting to anything more recent than 2010 is not an option.
The conversion process is usually pretty seamless, it will take your 2005 project and upgrade it to a 2010 project.
It should not be an issue unless you have projects with 3rd party components which, for whatever reason, do not like the newer version of Visual Studio. The only one I've ever had a problem with is Crystal Reports and that was going from a .NET 1.1 project in VS2003 to .NET 4.0 in VS2010. (But hey, one does not simply do things with Crystal Reports)
The conversion wizard will also back up your old project if you tell it to, although I would hope it's in source control of some kind anyway.
Of course, people who only have VS2005 on their machine will no longer be able to open your upgraded 2010 project, you are effectively committing to VS2010. It can always later be upgraded to VS201x at a later date if this becomes an option.
Which versions of Microsoft Visual Studio Express can edit rdlc files?
I need a free resource for end users to edit the reports to fix cosmetic issues without forcing them to purchase a full VS license.
If you create reports with VS2010 or VS2012 you must consider this fork:
https://github.com/majorsilence/My-FyiReporting
If you create reports with VS2005 or VS2008 you can use this:
http://www.fyireporting.com/ (*)
(*) EDIT (march 2017): THIS LINK DOESN'T SEEMS TO WORK ANYMORE; SITE WAS COMPLETELY REBUILD AND NOW IT IS ABOUT SEO
I have written dozens of custom code analysis rules. The rules were developed targeting Visual Studio 2010. As required, the assembly has a reference to version 10.0 of FxCopSdk, Microsoft.Cci, and Microsoft.VisualStudio.CodeAnalysis. They run correctly in Visual Studio 2010 and build properly in TFS 2010.
I'd like to migrate to Visual Studio 2012. When I run the custom rules on an existing solution using VS 2012, however, I get CA0062 errors. The root cause is a CA0053 error loading the custom rules assembly. I understand that these references to the three assemblies need to be updated to version 11 for Visual Studio 2012. This can be done using version redirects in config files. I can get this to work locally by redirecting the Visual Studio 2012 IDE and FxCopCmd binaries, but am running into trouble when checking code into TFS 2010.
There are two apparent solutions we have considered, but neither is very palatable. The first is to require each developer to redirect locally, and then modify the TFS build agents to redirect as well. The second is to maintain two branches of the custom code analysis rules, one targeting version 10 (VS2010) and the other targeting version 11 (VS2012).
Is there a better way to do this, or do we need to all upgrade to TFS 2012 and Visual Studio 2012 simultaneously?
You can try to manually edit the project file and write two include blocks (one for VS2010 and one for VS2012), then define conditions to use the correct one. You only have to somehow determine if You want to build for VS2010 or VS2012 in msbuild.
Between your approaches and the one proposed by ZFE, you pretty much have all the potential candidates. Given the choices, I would strongly recommend branching since there is no official SDK for FxCop with backward-compatibility guarantees.
If you're lucky, you won't hit any behavioural or API surface changes that affect your rules, and the only difference between your two branches will be the references, so any merges will be trivial. However, any time investment you make in an alternate approach now will be lost if you need to branch later, and the likelihood of eventually needing to branch is non-negligeable.