How do we disable the "Continuous Analysis" option in Klocwork by default?
I know how to disable it for the Eclipse plugin and for .sln files, which works fine, but this is an additional step that must be performed each time a user creates an .sln file or eclipse work space. And they end up checking out a license to do this (unless they modify the local.properties file directly).
Is there a way to set this to default to off globally, without modifying each MS Visual Studio / Eclipse workspace individually ?
Thanks!
There is no way to switch off CA globally in the current version. For better / more immediate feedback, you can use the community forums at http://developer.klocwork.com.
Related
Assuming I am only using Visual Studio Code as the editor, is there an advantage to include a .editorconfig file in a project if I already have workspace settings saved?
Or, a disadvantage: such as .editorconfig potentially overwrite my Visual Studio Code settings or vice versa?
TL;DR;
Basically, .editorconfig has advantages when:
you're working in a team
or
a way to preserve your settings, so you can easily use them in other projects in case you lose your existing IDE settings (e.g., customise stuff in your IDE but then format your computer)
More information
The .editorconfig file is usually committed into the code repository, so it can be used by multiple people working on the same repository. This enables you to have code consistency across all team members. You might like using tabs, but the rules are set to use spaces. Sorry, team rules override your personal rules. Consistency wins.
Visual Studio Code workspace settings (or any built-in IDE workspace settings) can be individually configured (per person) and thus could be different and make the files in the repository, inconsistent. You might use tabs while other people use spaces and it messes things up for everyone, because now you're all fighting on coding style(s).
.editorconfig files might require a third-party extension to work with your IDE (which is the case with Visual Studio Code) while IDE workspace settings are baked in to the IDE (no extra download(s) required). Note: Visual Studio (as opposed to Visual Studio Code) has this baked in.
IDEs usually allow you to 'back up' your IDE settings ... so it's true you can back up your settings and use them later on.
Not everyone in a team always uses the same IDEs. Again, means nothing if you're just working solo on something.
First off, .editorconfig only works in Visual Studio Code using a plugin. The advantage for .editorconfig is that other editors also recognize it. The advantage for Visual Studio Code workspace settings is that it doesn't require a plugin and can include more settings.
From what I can tell, .editorconfig takes precedence over user and workspace settings. Although I couldn't find an official statement on this (but also one hint is that they mention this not being true for one of the settings as a bug).
I would use .editorconfig for what I can and include the Visual Studio Code workspace configuration for the remaining settings. I'd avoid conflicting settings.
I would like to use Eclipse in an intro programming class. Is there some way I can make some kind of preferences file or some such that I can distribute with it that would set defaults for:
which buttons are in the toolbar
which menus are enabled in the application
which context-menus are enabled
what kinds of completions are available
I'd like it to start with only completing words from the current document
that is no Java API completions or code generation or whatever
This can be done using Eclipse Preferences File. All you need to do is import preferences into your workspace.
You can also export the workspace folder itself & publish Eclipse together with a default workspace folder, which will contain all the preferences.
Then create a shortcut to start eclipse with -data <path to your workspace> parameter
I'd try the following:
Install Eclipse
Put the configuration files and workspace under version control and commit.
Configure Eclipse as required.
Check all the changes in the version control to understand what configuration files are relevant to my changes.
Continue as Zilvinas is suggesting.
Look into Eclipse Oomph. It essentially automates all the tasks that you need to do to set up a fresh dev environment.
Also of interest are Yatta profiles which do a similar thing based off Oomph.
They're pretty easy to set up and publish. Get your local eclipse working, record to a profile, publish the profile, get your students to consume said profile. We've used these in a professional environment to more easily on-board new devs!
We've updated to Visual Studio 2017 and switched to Team Services (VSTS) as our source control. I've migrated a few old projects and am using the Microsoft Installer Project extension to provide compatibility for the original setup projects.
However, there seems to be a potential issue with source control when working with the setup projects. Attempting to make any change results in the error:
The command you are attempting cannot be completed because the file 'Setup[Productname].vdproj' is under source code control and is not checked out.
Modifying files of other projects within the solution work correctly and trigger checkout from the repository.
I have not been able to determine a way to properly check out the setup project and work with it under the new source control. I'm unsure if it's a bug with the extension or if it simply lacks support for VSTS.
Has anyone successfully been able to work with setup projects (.vdproj) in conjunction with VSTS? If not, is there a workaround?
Edit:
Image of context menu:
You can apply the following workaround, since it seems to be a bug in the installer extension:
Choose 'Open file in File explorer' in your context menu
Open the project file in your favorite texteditor
Make a dummy change (adding a space character in an empty spot is enough)
Visual studio will prompt to reload the project and has explicity checked out the project file.
see also here
I submit a feedback here: The command you are attempting cannot be completed because the file 'Setup[Productname].vdproj' is under source code control and is not checked out
The workaround is that you can check out the project manually. (Right click the installer project > Check out for edit)
I'm using Eclipse Mars with the TFS plugin. I work with many files that don't have a file extension. Is there a setting to have those files open in Eclipse? Currently, I always get Windows "what do you want to do with this file" selection displays.
All of these non-extension files are plain text that would properly render in Eclipse.
We have a fix in TEE/Eclipse TFS plugin to handle opening files without any extensions from Source Control Explorer in Eclipse. It will be available with our next update.
Thanks,
Madhuri
Jacob:
Unfortunately, the way our Eclipse TFS plugin (i.e. TEE) is written today, you will not be able to do what you are asking (meaning, you will not be able to configure the system so that when you click on a file with no file extension in the source control explorer and have it open in Eclipse – you will always be promoted by Windows to choose the application). We will keep this use case in mind as we continue to support the plug-in and will add it to the backlog of options to be considered in the next release. We are sorry for any inconvenience this is causing you. Thank you for your question.
I would like to maintain a log of changes made to all files of a project while working in a Netbeans session. This would be useful to undo/review changes made while debugging the project.
Is there any plugin that would maintain a log of such file changes ?
I use Netbeans 7.2. for Java Projects.
I would suggest you use a real version control system. There are plugins for NetBeans. I've yet to see some automated system appropriately handle the task of source code change tracking.
If you want it for quick/temporary use:
Download and install Netbeans plugin 'Local History' through Tools->Plugin. After you reload your IDE and save a file multiple times, you'll be able to see a History view for your file. You can see differences between the revisions, restore etc.
If you want maintain revisions and permanent use, I would recommend using "git".