I have used FxCop 1.36 and I recently upgarded to FxCop 10.0. Using the same set of rules and the same set of assemblies now I got less warnings.
Have they removed some rules from the FxCop 10.0? If so, why?
I know of only one rule (Performance.DoNotInitializeUnnecessarily) that appears to have been completely removed in 10.0. However, there are some other changes that may be affecting your violation counts:
The logic of several rules has been improved so that they will detect less false positives. For example, there are some security rules that detect issues that are only problems when running on .NET 1.x. If you target later framework versions, you should no longer see violations for these rules in FxCop 10.0.
The rules around security transparency have changed quite a bit. Some old rules have been removed, but they've been replaced by other rules that should detect similar problems. In addition, quite a few new transparency rules have been added. Depending on whether you've upgraded your code to .NET 4.0 and how you've set up your transparency/criticality, you may be picking up less transparency violations than you did before.
it's difficult to trac the different versions of fxcop. Is version 10 compatible with 3.6?
Can version 10 also profile .net 3.5 code?
Related
I have a .Net 4.6.1 Winforms application which has more or less 10 years.
It has worked pretty well since the beginning, but in the last few weeks I faced a problem I never had.
Firebird 2.5 (latest version available)
.net client (latest version available)
Visual studio 2015 or 2019 (in both versions, same problem)
Now, the application, when is about Firebird, calls a sequence of select statements in order to load a dataset. It works well, as usual, as it always worked. Since few weeks, the whole sequence of select statements is slow, tremendously slow.
What do I mean with slow? It usually takes 5 or 6 seconds in my PC to load the whole set of data, now it takes 70 seconds, with no reason. Nothing has changed in the architecture or sequence, nothing was added or removed from the environment.
However, I don't know why, the release version of the software is fast as it was originally, so I don't really get where the point is here.
I have a debug version in Visual Studio which is slow at loading the data using a set of select statements, and a release version which is fast as usual.
Now, when I first realized that the software was running very slow, I upgraded the whole set of Firebird components to the latest versions, but had no joy. I was still using old versions because I had no real reason to upgrade: "does it work? Don't touch it!"
In the release version I use the embedded Firebird version, because I have to redistribute the application. In the debug, the server version, so I can manage the database with IBExpert and run the software together. It has always been like this since ages.
So, I'm looking for a suggestion, because I have no idea where or what to look for.
I fixed this odd behaviour by setting Pooling=true in the connection properties
Does it apply to any aspect?
Is that it?
If I use a multicast attribute it will apply randomly to the first 10 matches only?
I'm not sure if I got this restriction right. Do you mind elaborating it a little?
Examples would be well welcome'd.
Starting from PostSharp 4.3, this limitation applies to any aspect. The build will fail if you apply aspects to more than 10 targets (with Multicast or not). So no randomness happens.
If PostSharp 4.3 detects that your project would have been built successfully with PostSharp 4.2 or prior, then the backward-compatibility mode is enabled and the project will be built by PostSharp 4.3 without error. Please refer to PostSharp 4.2 API documentation to check if an API used to be available in PostSharp Express.
I'm looking for a sort of history lesson. I'm a latecomer to PowerShell. I learned on version 4 and I have a growing number of commandlets that I'm contemplating using in places where version compatibility matters. Most of my unit tests are passing when I run powershell -version 3. On the other hand, there is a sea of red when I run powershell -version 2. Rather than blindly reworking my code-base to try to make it friendly to pre-v4 versions of PowerShell, I'd like to get some sort of understanding what that would entail.
There are some posts that speak to some differences between versions, but I haven't found anything canonical, nor have I found any that take the retrospective perspective needed to undertake making a codebase backward compatible.
Here are my specific questions:
What are the major things missing from earlier versions of PowerShell that code written for later versions are probably relying on?
Are versions of PowerShell itself backward-compatible? That is, if a well-written script runs correctly on version 2, can I expect it to behave the same way when run on versions 3, 4, and 5?
This question is too broad to get a good answer. I would suggest reading What's New in Windows PowerShell to get the highlights of what's changed.
PowerShell is backwards compatible with scripts written for earlier version of PowerShell. I won't say 100%, but I can't remember having heard of any problems. Newer versions have extended and simplified existing cmdlets and introduced a lot of improvements, but AFAIK nothing has been removed or broken. Even Snap-ins are still supported in 5.0 even though they were replaced by modules in PowerShell 2.0.
Ubuntu is usually a cutting edge distro. But why does it stick to a 2011 version of Eclipse when we are 4 years into 4.x development?
It's not even optional and cannot be installed from the repositories. And it's not 'easy' from a download either. For some reason, the Java SE 7 reference implementation, OpenJDK, is not enough, and you need the Oracle version. Why? This isn't available from the repo's either, and you need some weird untrusted 3rd party repo for that or follow a whole chapter on how to install it yourself.
There were problems three years ago. When Juno 4.2 came out, it had a lot of performance issues. Eclipse Director Mike Milinkovich explains one of the reasons is lack of funding. For the first time in a major release:
"The performance test were turned off because the Eclipse platform team has a serious resource issue."
For that reason, developers released unnamed and unpromoted version 3.8 simultaneously with 4.2 to bridge the gap for this (hopefully) temporary problem, and it's popularity caused a notable trend downwards amongst developers. As one Eclipse b3 developer mentioned:
"I was stunned by the performance improvement after the switch. The 3.8 platform is much MUCH faster"
The 3.8 release is still a popular alternative to the 4.x branch among developers (ask my colleagues or google), I think mainly because of (genuine) trust issues. But the bridge (read: support for 3.8) has closed now that 4.3 is released.
The core problems (funding and developers) have not been fixed though, as seen by Google's gesture of donating money to the Eclipse Foundation in the hopes that other companies will follow suit. Does this mean that 4.3 is still not up to par with the 3.x standards?
This is not a problem with a plugin or a feature for a specific language, this is a problem within the core of the platform itself. (But I'm using WST with Javascript and V8 plugins for PHP and Node development in particular.)
This is not a specific platform problem either. There are similar complaints from Linux, Windows, and OSX users. (But I'm using Linux (Mint 13).)
On the one hand you have people telling the EOL for 3.8 "proves" that 4.3 is fine now. On the other hand (see comments):
"I've moved back to 3.8 due to constant crashes on ubuntu with 4.3"
3.8 is far from problem-free and I wouldn't mind to get a smoother development experience. So I am wondering, why is Eclipse 4 'kept from us' by the people who decide what software versions are 'good for us' (AKA what goes into the official repository)?
lucid (10.04 LTS)
Eclipse 3.5.2-2
precise (12.04 LTS)
Eclipse 3.7.2-1
raring (13.04)
Eclipse 3.8.1-1
saucy (13.10)
Eclipse 3.8.1-4
trusty (14.04 LTS)
Eclipse 3.8.1-5.1
utopic (14.10)
Eclipse 3.8.1-5.1
Update 2014-05-30: I just tried Kepler (again) and it still suffers from UI glitches out of the box. E.g.:
And no, changing the inactive window toolbar background color in preferences does not fix this. (Even if it would, this would be a silly default choice).
I would like to know, from someone who is not positively or negatively biased because of their own highly specialized and tweaked workflow - preferably from someone with experience in the Ubuntu package maintaining process for non-trivial packages - why this decision is made by a team of professionals who know what they are doing for the most widely used Linux distribution out there?
Eclipse Juno was released 2012-06-27. On 2012-07-17 a bug concerning the responsiveness of the UI was reported. Four months later, around 2012-11-14 the first patch was released to the official update-site.
Many users, however, completely missed the release of the patches. I assume the information drowned in the FUD, and other more important news, that was spread around that time. At the end of 2012 I posted an answer on SO. Apparently I was not the only one for whom the patch fixed this performance issue.
On 2013-02-22 Eclipse 4.2.2 was released, which contained the same patch, yet I kept receiving upvotes for my answer on SO until June.
Probably the only known fact among developers is that Eclipse had serious performance issues at some point. However, the knowledge about scope, magnitude and duration of these issues seems to me like a series of common misconceptions.
There was a four months period during which it was a good idea for many Eclipse users to stick with the 3.8 branch. I say "many" because I worked with 4.2.0 and 4.2.1 and it was O.K. for me. Subjectively, switching tabs was about two times slower and the IDE froze maybe once a day for a couple of seconds. For colleagues of mine the problem was much more severe. I assume it depended on your setup and on your workflow, however, I never felt like investigating further because I knew the platform developers were working on the issues, and there was a good fallback, using 3.8.
One year and three Eclpse releases later these serious performance issues are still fixed.
Of course, this doesn't mean that there are no more performance issues. As of now I find 1979 reports in the Eclipse bugzilla with the keyword "performance". This doesn't mean that Eclipse is very buggy, but only that it is very well documented and open. Whether or not you are affected by any of these issues, again, depends on the setup, the plug-ins you are using and your workflow. I am a Java, plug-in and EMF developer. I work with medium to big work spaces (~1M LoC), and Eclipse 4.3.1 is fast enough. The 3.8 release is not an option for me because as Eric said, it won't receive all of the important updates. People will still continue using it in the future. Many of them will also continue using Internet Explorer 5.5.
If you try the 4.x branch and notice any performance issues, please report them, but be specific about your setup.
From the official Wiki page:
Several major performance defects have been addressed in Juno SR2
(4.2.2). Community members have confirmed that these fixes
substantially address the performance problems with editor and view
opening, closing, and switching. These fixes are widely available in
Juno Service Release 2 (February 2013). All defects are also resolved
in the Kepler (June 2013) release stream.
new Features
Your statement "3.8 release was specifically released as a faster and more stable alternative to 4.2" is clearly incorrect; 3.x has gone into its 'end of life' maintenance and was most certainly not released as an alternative to 4.x.
While folks are welcome to continue to use the 3.x stream if it suits their needs please recognize that as the various projects move forward there will be significant divergence in the features available between the two versions...
I have a Movable Type site running MT 4.38, and I was wondering whether I should upgrade to 5.
For a while, MT 4 and 5 seemed to have been developed concurrently, but now I only see activity in MT 5. Has MT 4 been abandoned?
The person using the site is change averse, so I only want to upgrade if it's absolutely necessary (i.e. security issues).
Thanks
Yes. Movable Type 4.38 has a patch for a security vulnerability which you should be sure to apply. But beyond that, you should absolutely upgrade to Movable Type 5.2.3.
The big reason is that Movable Type 4.38 will be end-of-lifed on December 31, 2013. This means that there will be no security updates for Movable Type 4.38 after that date.
Movable Type 5 has a number of great new features that are huge improvements over MT 4.38:
New and improved Rich Text Editor based on TinyMCE
Revision history on the most-used objects in the CMS
List-management framework enhances Movable Type's ability to manage large amounts of data inside the CMS
Sortable categories and folders
Template tags for things like mt:EntryPrimaryCategory
Enhanced multi-blog support
Huge support improvements for Webkit-based browsers (Safari and Google Chrome) as well as IE 8 and 9
Login failure detection, allowing either account or IP address lock out
With all due respect, no one should be running a version of Movable Type that is no longer supported with security patches. It's foolish to think that any one person can know all of the possible security issues in an older version of a Content Management System such as Movable Type.
Yes, MT4 is no longer developed. It still receive security patchs every few months, but there will not be a new version.
As for what you want to use, MT4 and MT5 have a different set of plugins. So if you want to upgrade, check that the plugins that you need support MT5 or have a MT5 replacement.
Upgrading would work without any problem if you are not using 3rd party plugins.
If you're using 3rd party plugins, you might encounter compatibility issues because the v5.x architecture is much different than 4.x.
Before considering to upgrade to v5.x you may like to check your 3rd party plugins and see if there is a version that works with v5.x.
Another thing to consider is to clone your installation and try to upgrade it on a different domain/folder or on a stage server where you could check that everything works before upgrading your live installation.
Alternatively you could order a professional movable type upgrade service from:
http://www.movabletypeupgrade.com/