As said in the title, I cannot find any vulnerabilities in my project using the bundled Package Search plugin to find dependencies vulnerabilities.
I use IntelliJ IDEA 2022.1.3 (Ultimate Edition), and I checked it by putting for example the spring-boot-starter-parent version to 2.2.1.RELEASE, which contains severe CVE vulnerabilities.
So In fact yes it works perfectly and is awesome.
But was bugged in previous version.
https://youtrack.jetbrains.com/issue/IDEA-294147/Intellij-IDEA-show-vulnerable-dependencies-not-working-when-an-IDE-is-activated-not-with-JetBrains-Account
MY colleague had his personal licence activation before using the company licence server, that's why it worked on his side.
package-checker works fine as is out of the box with IntelliJ IDEA 2022.1.4 (Ultimate Edition)
it's quite awesome, actually
i do have colleagues where it is not working with intellij-c though, which would be nice to resolve
Related
I just made a clean install, as I do every year, of my linux system (ubuntu) on my notebook.
I just wanted to open-up eclipse from my (old) workspace, where all my code from the past 12 months is - but eclipse doesn't show a single package!
My assumption is that I used an older version of eclipse up until yesterday before the clean install, and that the version I installed today is newer, thereby doesn't recognize my worksapce(s!). Is this assumption correct? if so, Does anyone know how I can figure out which version of Eclipse I was using when working on the old Workspace, so that I can download that exact same version again?
The absolut worst-case scenario would be to c/p all classes and packages manually into the new eclipse, but it's over a 1000 classes - so that might be too time-consumming.
An help would be greatly appreciated, since there actually are 2 projects from work in those workspaces... ^^
Well, after Downloading Eclipse Mars, I found a solution. Although switching workspaces, or even importing the old workspaces didn't work, I found out that if I started eclipse from the old workspace, even though package explorer would stay empty, it would suffice to define a new java project with the exact same name of one of the projects inside the old workspace, for eclipse to instantly load-up the docs contents.
This not as much a solution, then a work-around... but still, fixed the problem!
I've encountered a problem after upgrading from Visual 2015 RC to Full version. Fody.PropertyChanged doesn't work in UWP (it worked with RC). After using reflector there is no raisepropertychanged injection, no warnings, nothing. Any ideas?
EDIT: it doesn't even create FodyWeavers.xml after installing it with new Nuget.
The reason is that Nuget deprecated several features for Universal Projects
See here for the full details https://github.com/Fody/UniversalAppSample/
Currently I have licenses for the following JetBrains products:
ReSharper 8.2.0.2160
Dotcover 2.7.1.238
I recently needed to use Dottrace, so installed the latest version from the JetBrains website. However I found this is incompatible with the other, earlier products, so uninstalled it.
Except it didn't uninstall properly. I still see dottrace menus, which still appear to function, and ReSharper is still broken. I have tried completely uninstalling and then re-installing Visual Studio (together with resharper and dotcover), yet this has still not improved anything. I still see Dottrace menus and ReSharper is still broken.
I've tried the JetBrains support forums (https://devnet.jetbrains.com/message/5536694#5536694), but they have not been helpful. Has anyone here experienced a similar issue, or have ideas as to how it can be resolved?
I'm starting to get desperate. Is there any way I can fix my development environment short of completely re-installing windows?
The problem was solved by JetBrains support. In case anyone else has the same issue, all you need to do to solve it, is to delete the directory:
C:\Users[user_name]\AppData\Local\Microsoft\VisualStudio[version_number]\Extensions\JetBrains
I am trying to compile the vNext branch of MvvmCross on a Mac to try & start doing some iOS development using PCL's & MvvMCross.
I have spent a couple of days on this now but appear to be going in circles... being somewhat new to both C# & the Mac.
I have installed MonoDevelop 3.1.1 as recently referred to on #slodge's blog.
I have updated the targets file as per this reference https://files.xamarin.com/~jeff/Microsoft.Portable.CSharp.targets
I have downloaded the vNext branch from GitHub.
I have loaded the mvvmcross_all.sln in MonoDevelop however building it using the Debug|iPhone Simulator profile gives me 3 errors.
I have not been able to work out how to fix the references errors as for example appear in CrossUI.Core, ie references to
System
System.Core
System.Net
etc
Each of these lines has an error of Assembly not available for .NetPortable 4.0 Profile1 Profile (in Mono 2.10.9)
I realise its all a moving target but its obviously possible to get it to compile.
Any suggestions as to what I may have missed would be appreciated.
TIA,
Andreas
Thanks Andreas
In the version referenced in the blog at http://slodge.blogspot.co.uk/2013/02/a-patched-monodevelop-for-pcls.html, it appears that MonoDevelop reports that CrossUI is missing its references - but it still compiles. See this screenshot from my Mac - solution explorer reports problems but 'rebuild all' on CrossUI succeeds.
If you get problems with building, please do report the build output and I'll try to help.
Note that the patched version of MonoDevelop also still has other problems - e.g. syntax highlighting and intellisense issues- MonoTouch: creating multiplatform apps using Portable Class Libraries
Alternatively, there are some iOS/Mac friendly binaries on SkyDrive - http://slodge.blogspot.co.uk/p/mvvmcross-binaries_7.html
The schedule for 'proper' support of Portable Class Libraries is aiming for a demonstrable version before Evolve (so less than 2 months away). Until then I'll personally continue to do most of my PCL work in VS, with the platform specific steps in MonoDevelop.
When using 3rd party libraries/components in production projects, are you rigorous about using only released versions of said libraries?
When do you consider using a pre-release or beta version of a library (in dev? in production, under certain circumstances)?
If you come across a bug or shortcoming of the library and you're already committed to using it, do you apply a patch to the library or create a workaround in your code?
I am a big fan of not coding something when someone else has a version that I could not code in a reasonable amount of time or would require me to become an expert on something that wouldn't matter in the long run.
There are several open source components and libraries I have used in our production environment such as Quartz.NET, Log4Net, nLog, SharpFTPLibrary (heavily modified) and more. Quartz.NET was in beta when I first released an application using it into production. It was a very stable beta and I had the source code so I could debug an issue and there were a few. When I encountered a bug or an error I would fix it and post the issue to the bug tracker or author. I feel very comfortable using a beta product if the source is available for me to debug any issues or there is a strong following of developers hammering out any issues.
I've used beta libraries in commercial projects before but mostly during development and when the vendor is likely to release a final version before I finish the product.
For example, I developed a small desktop application using Visual Studio 2005 Beta 2 because I knew that the RTM version would be available before the final release of my app. Also I used a beta version of FirebirdSQL ADO.NET Driver during development of another project.
For bugs I try to post complete bug reports whenever there's a way to reproduce it but most of the time you have to find a workaround to release the application ASAP.
Yes. Unless there's a feature we really need in a beta version.
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
I'll use the patch. Why write code for something you've paid for?
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
Good point, I was also considering the scenario of evaluation of the pre-release version in dev, but I supposed that taints the dev -> test/qa -> prod path.
I'll use the patch. Why write code for something you've paid for?
What if it's not a commercial library, but an open source one? What if the patch to be applied is not from the releasing entity (e.g. your own patch)?
I use:
Infragistics (.NET WinForms controls)
LeadTools (video capture)
Xtreme ToolkitPro (MFC controls)
National Instruments Measurement Studio (computational libraries, plotting, and DAQ)
I've found significant bugs in every one of these, so I try to limit their use as much as possible. Infragisitcs is pretty good for what it is, and National Instruments is by far the best, although quite limited. I would avoid LeadTools at all cost.