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.
Related
I have a home grown project (https://github.com/andybantly/MFC-Fractal) that I have been working on since the Visual Studio 2005/2008 days. I just recently put it in Git. Its home is on CodeProject.
I am not sure when this started (maybe 10 years ago...) but when I migrated my application to the latest version of Visual Studio, new/odd behavior injected itself into the code generation step. The IDE has somehow decided that when I build the source that I really wanted to build and run the source. This is somewhat annoying, especially during a batch rebuild all.
I am looking for helpful suggestions on configuring the IDE to prevent this behavior. It never used to do this out of the box.
Is it a show stopper? Absolutely not. Is it annoying? Depends on the side of bed I woke up on.
We are attempting to upgrade our rather old TFS environment from TFS2008 to TFS2015. The upgrade of the server and database is not a problem and is fine.
The issue is our build machine. This is still a Windows 2003 Server that is running Visual Studio 2010 and VB6. We still have a need to use this build machine to build legacy VB6 projects. We have installed the TFS2010 XAML build controller on this server and successfully connected it to our test TFS2015 server. However when we try to run a Xaml build, (any Xaml build regardless of whether it builds VB6 or .NET) we get the following error message almost straight away.
TF900560: Could not start build: Cannot set unknown member 'Microsoft.TeamFoundation.Build.Workflow.Activities.TfsBuild.TargetsNotLogged'.
The XAML build are using the 'UpgradeTemplate.xaml' template and using the TFSBuild.proj we used under Visual Studio 2010.
We have a also set up a TFS2015 build controller on another (Server 2012) machine and that successfully starts the build process. However, our VB6 projects use a lot of third party components that will not install on Server 2012 so we can't use that.
Has anyone ever set up this kind of arrangement before? Is there anything we are missing or are doomed in this scenario? Obviously, we'd like to move away from VB6 apps, but that is not possible in the medium term.
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.
Is it possible to use Wix with Express editions? I am interested in 2010/2012 versions. I know I can use candle and light from the command line, but I am interested in integration with IDE
The Express versions of VS does not allow to extend the VS with the necessary plug-ins. So you have to stay with the command line.
Alternatively to VS you could try WiXEdit.
Actually, if the goal is to have a free installer suite, WiX is perfectly happy installing into Visual Studio Shell Integrated, which is freely available. All features of WiX are available.
The only limitation is you have to open a different instance of Visual Studio in order to build your installer, but I haven't found this to be limiting in the slightest, and in fact I appreciate the separation of concerns.
Of course, another solution these days is to simply use VS Community Edition.
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.