Style Cop rules don't work - visual-studio-2010

I added Parent Settings File to the solutions folder. After that I unchecked there rule SA1101 in the parent file. Also I set "Do not merge with any file" in parent file, and set merge in the parent file in the project`s settings file.
But after I build project I get this error. I attached window with error and settings winwows - there are no overloads or something like this.
I really don`t now what I can do, to resolve this issue....
ADDED.
But in resharper all rules work normal. But when I try to build solutions - my settings are ignored.
I used StyleCop Version 4.5.24.0

The problem is in Style Cope For Resharper. I tested the same solutions on another PC and all works fine

Related

VS2013 displays incorrect configuration in property page

Short version
VS2013, switching property page views of files to a certain configuration shows the wrong configuration!
Long version
I have a solution with several projects, each project containing a "Debug", "DebugRelease", and "Release" configuration.
For the projects, viewing the properties in the property page viewer (right click, choose "Properties") displays the configuration settings corectly.
For individual files, viewing the properties in the property page viewer looks correct in Release, looks correct in DebugRelease, and Debug seems to display the same properties as DebugRelease.
In fact, making any changes and saving them causes the project XML to make changes for "DebugRelease". Additionally, making changes in "Debug" causes "DebugRelease" to change as well... Seems like "Debug" for some reason isn't being displayed.
Compiling seems to compile to DebugRelease as well, even though the solution configuration is set to use Debug across all projects.
If I rename the "Debug" configuration to something that's not a prefix of "DebugRelease" it seems to work okay. If I rename it to a prefix, however, the same problem persists.
More vexing still, I have other project configuration names that are similar (BlahBlah_Debug, BlahBlah_DebugRelease, and BlahBlah_Release) and only some of those display similar behavior -- some of them work fine.
Problem first noticed under VS2013.4. Updated to VS2013.5 and it still persists. This didn't used to be an issue.
The obvious work around is to rename the project configurations, but there's a decent amount of tooling that expects the configurations as they already are.

How to delete user-defined build settings in Xcode 4.3.1

I have created several user-defined build settings in Xcode 4.3.1. I no longer need these settings and want to delete them, but there doesn't seem to be a way to delete them!
I am aware that these are stored in the project settings (project.pbxproj) file located within the xcodeproj file. But I don't want to edit these in a text editor as there are all sorts of repetitions and guids which I don't understand.
Any suggestions on how I can do this within Xcode? (or have they forgotten to add a "delete" button)
Just figured this out myself: you need to make sure you're at the right scope to be able to delete the setting. If you defined the setting at the project scope, no amount of key-bashing will remove it if you're looking at the target-scope. Remember, targets inherit settings from project scope. That last bit is what I tripped over :)
Try selecting a user-defined setting that you created then hit "Delete" button on your keyboard. That works for me when I encountered the same problem.
On Xcode 6:
Select the row and hit Fn + Delete.
Follow the steps below:
Select Project
Tap on the Info tab
Select Configurations
Select Configuration to remove
Press the Delete button on the keyboard
Removing User-Defined build settings depends on where those settings have been created.
Lets assume that you've created one already and named it as PROJECT_SETTING. In order to check your PROJECT related User-Defined settings, you have to select your project first on the project and targets list, then you should see something like this:
Here you can see only PROJECT related settings, and here you have the
only ability edit/delete PROJECT_SETTING.
Besides that if you set up a TARGET, so can add new User-Defined settings there, that only affects that TARGET scope.
You can edit/delete TARGET_SETTING_1 and TARGET_SETTING_2 here, but
PROJECT_SETTING is read-only, as it is inherited from your
PROJECT settings.
Here you will notice that your TARGET contains your PROJECT User-Defined settings and also your TARGET related User-Defined settings marked as bold letters. This helps you to know which setting can be edited on this level.
You won't be able to delete your settings here if that was created under PROJECT scope, and also editing a PROJECT related User-Defined settings will result a newly created settings that affects only the selected TARGET.
Also if you prefer more visibility on Build Settings, you can select Levels view instead of Combined view, so you should see it more separated:
Select one of them and press keyboard's delete button.
There's a caveat to these answers: If you're using a Build Configuration File (.xcconfig) it doesn't seem possible to delete the user-defined settings generated from these files directly on either the project or target level in the "Build Settings" GUI. You'll have to delete the flag and its value from the configuration file and rebuild the project. If you're using multiple build configuration files that use the same flag, you'll have to delete them from each file.
Although settings that come from these configuration files are displayed in the User Defined build settings section (just like any other user-defined flag that one would create from the GUI), they are not written to the .xcodeproj file like the settings that one adds from the GUI are (which probably prevents them from being able to be deleted from the GUI). They are also not displayed in bold text like these GUI-added settings are.

Can't switch from release to debug configuration in Visual Studio 2010

I downloaded an ASP.NET open source solution and opened it in Visual Studio 2010. VS is running as admin.
Everytime I switch the solution or a project from Active (Release) to Debug and uncheck 'Optimize code' and save, these changes don't stick. The solution or project reverts back to Active (Release).
Why is this happening?
You also have to change it in Configuration-Manager (see pictures).
I just had this exact issue. The solution ended up being:
Go to Tools ⇒ Options ⇒ Make sure "Show All Settings" in the lower left is checked.
Then, in that same window, go to Projects and Solutions ⇒ General ⇒ check "Show advanced build configurations".
I have no idea why this checkbox was suddenly unchecked for me this morning, but this worked.
This is guessing a little, but anyways:
Most likely, you are using build configurations that don't include your start up project for Debug build.
Look for the 'Manage Build Configurations' (I think, no Windows machine nearby) menu item. It will show you a list of projects with tickboxes on the right to show whether it is to be built in the build configuration.
Switch to 'Debug' in that dialog and make sure your startup project - or the project that your starting the build for - is actually included in the build.
PS It is even entirely possible that the 'misbehaving' project is actually lacking a Debug build (it might have a deviant name, like DebugConsole or something else entirely). In that case, use the Project menu to add a build configuration of the proper name for that single project. Afterwards, check (again) that said build configurations are checked in the 'solution wide' build configuration dialog.
HTH
Changing the properties of a configuration doesn't change the current build configuration. If you open project properties, change from Release to Debug and make some changes, after exiting the dialog, you will build on the same platform as before. To change the platform you're building on, there is a combo-box right above the code - use that. You should have all available configurations in the list. When you open the project preferences dialog, the current configuration will be the default one in the dialog.
I opened the csproj file in a text editor. Noticed there were two PropertyGroup sections which look like duplicates, one was Debug|AnyCPU and the second was Release|AnyCPU. I deleted the second one and the debug one showed up.
Luchian Grigore's answer explains correctly one simple misconception that could lead to this problem and aaaaaaa's answer gives another way of correcting it: there is a dialog that looks like you are selecting the configuration to build but you are actually just selecting the configuration to configure.
However neither of their ways of opening the 'Configuration Manager' actually worked for me -- I had to click on the button configuration manager at the top right of the solution Properties.
(Note that the place where you choose the configuration is called Configuration Manager, whereas the place where you manage the configurations is Properties.)

This Breakpoint Will Not Currently Be Hit, The Source Code is Different from the Original (even after cleaning/rebuilding)

.NET 4, console application. The project is set to 'Debug' mode. The breakpoint being set is in the primary/startup project. I have right-clicked -> Clean, and right-clicked -> rebuild, both on the Solution and project levels.
Following the instructions in this SO question, I have confirmed that my "Build and Run" options are set to 'prompt' for both 'When projects are out of date' and 'when build or deployment errors occur', and I am NOT getting a prompt when I F5 to build/run.
Also, the 'save all changes' under 'before building' is also selected (plus I manually saved them myself).
I monitored the output window of the application, see this line:
'MyApplication.exe': (Managed (v4.0.30319)): Loaded 'C:\exepath' Symbols Loaded.
I restarted the VS2010 instance. I restarted all open VS2010 instances (of other projects). I've even gone through a reboot.
However, the breakpoint I am setting in the startup project is a hollow-red circle, with the notice that 'This breakpoint will not currently be hit, The source code is different from the original', and, in fact, is never hit.
So, this is really 2 questions:
1) How do I fix this problem so I can properly breakpoint
2) When I see this, does that mean my code is executing from an older build?
I've had this problem once myself but that was on a vsto addin. In that case there were left over intermediate files under the users/appdata directories that were actually loaded instead of my app.
There is this blog article that has a whole load of possible reasons for this error and then a whole bunch more in the comments from other users
This can also happen if you have a solution with multiple projects, and have the wrong project selected as your startup project in VS2010 and VS2012.
Now, obviously, I wouldn't expect debugging to work if I have the wrong startup project selected -- the debugger is attaching itself to the wrong process!
But this error message (in my case) was terribly misleading. It made me think something else was wrong. I tried a bunch of solutions in this thread (nuking various /bin and output directories) when really it was something very simple (wrong startup process).
If you are using vb, check that you are building the project for the active solution configuration (Build, Configuration Manager..., Column under Build is checked. Also check the project properties, Compile tab, Advanced Compile Options, and Generate debug info is set to Full. Sorry I can't tell you where this may be in C#.
The only other time I've seen this is when two projects in the solution are referencing the same dll but they are referencing from different sources. One from a project reference and another from a file reference for example. If the "copy local" option is true, there would be the potential of overwriting the dll with an older version of the same dll.
My solution might help people who have signed the assembly.
After lot of head scratching for the past two days, I was able to resolve the same issue by doing the following simple steps:
Go to your Visual Studio project properties.
Go to the "Signing" tab.
Uncheck "Delay sign only" option if it is checked.
Now run your project and it should work.For me it did work.
In my case was this same problem (“The breakpoint will not currently be hit. The source code is different from the original version.”) caused by fact, that I tried add breakpoint to declaration:
DateTime dt;
bool b = DateTime.TryParse(null, out dt);
(first line of code)
So I assume that message is "universal" and may have many different causes.
This can happen if your system clock was changed since the last compile. Your PDB file will be different date than the one your are trying to debug. Delete the PDB files in the project and recompile.
I experienced the problem when Project > Properties > Web did not have "Enable Edit and Continue" selected. After enabling this feature the issue was corrected.
It is important to note that under Tools > Options > Debugging > Edit and Continue "Enable Edit and Continue" was selected, but it was not enabled for this project.
Just go to Tools / Import and Export Settings
Choose reset all settings then click Next
No, just resetl settings, ovewriting my current settings then click next
Choose your current language, por example C#. then click Finish
If you have multiple solutions open, try simply closing all Visual Studio instances and restarting only the instance you need.
In my experience this has happened when two branches of nearly identical code are open in different instances.
doing a "clean solution" from VS Build Menu might help you.
I had to go over all those steps to fix the issue on my computer.
Make sure that debug = "true" on your web.config
Clean and rebuild all projects
Delete every file inside the bin folder of all projects
Close and open Visual Studio, rebuild, and run the project again.
Go to your solution folder -> obj -> Debug - > delete the .dll file and build the solution again.

VS 2010 Unable to remove inherited additional dependencies

Hi by mistake I added cv210d.lib, cxcore210d.lib and highgui210d.lib as inherited values under the project configuration->Linker->input->Additional Dependencies settings.
But I cannot seem to remove them from the "inherited" additional dependencies. So each time I start a new project I get an error because these liberties cannot be found.
There is an option to ignore the inherited dependencies but I cannot do this as it contains values I do need.
So I am looking for a way to remove these unwanted values from the "inherited" additional dependencies.
You can find the file "Microsoft.Cpp.Win32.user" on your system and manually edit it as you want. Normally the file will be located at "C:\Users\%USERPROFILE%\AppData\Local\Microsoft\MSBuild\v4.0" location. It is an xml file.
As was suggested I modified the property sheet in the property manager.
The reason I found it confusing though was that in the Property Manager view, there are three different ways to change the properties. Through clicking on the debug, release property sheets or the project properties . But when I opened each one I thought I was opening the same thing, as they look similar.
But the case is that, the properties from the debug and release property sheets are inherited to the project properties. And you cannot modify the inherited properties from the project properties.
Did you accidentally add it to "Linker > Input" under "Property Manager > AnyProject > AnyConfiguration > Microsoft.Cpp.Win32.user"?
Despite its strange position, this is the setting for all projects of the current user.
As soon as you put a wrong .lib file into Additional Dependencies it went to the inherited directory. You need to untick "Inherit from parent or project defaults". Then, to save inherited .lib files (such kernel.lib and etc.) you need to copy and paste all of them into the Additional Dependencies directory. So your computer cannot take the wrong .lib file and will use only Additional Dependencies which you wrote
You can open with notepad the .vcxproj file of your project and find the lib you want to remove. Then, Delete that library from the xml field.

Resources