I'm working on a .NetCore 2.2 project, my question is about the folder Analyzers in the Dependencies, What are these,
And in some cases, they have a warning, which makes all dependencies folder has a warning.
Okay, it has no effect on the build on Runtime.
What are the analyzers?
Why they have warnings in some cases?
Those are roslyn analysers. They help you maintain high code quality.
Library authors for instance can use analyzers to raise errors/warnings/suggestions when users write less-than-ideal or plain low quality code.
If you have the warning sign, your project most likely also has warnings on build. You may expand the node in the question's screenshot to see a list of warnings and start addressing them.
The Visual Studio integration is documented here.
Once you're done clearing the warnings you may also consider using the FxCop analyzers.
Related
I've been using .NetCore for some smaller projects and I generally love it, but there are a few issues, of which one has been irritating me quite a bit:
In this example a lot of the configuration stuff uses extension methods to hang extra features off of Json, Command Line, Object Binding etc... In these cases all of which live in separate packages. When you see some code examples which typically include one or more of them you naturally copy them into a project to try them out, giving you compile errors when you try to build them.
Asking VS for guidance (pressing good old Ctrl Dot), doesn't help and so you have to search for the relevant packages you need followed by more searches in Nuget installing each one as required.
So my question is (Drum Roll Please) am I missing something or is there a tool/setting or extension that can give me suggestions based on exported extension methods on Nuget's public packages when you press Ctrl Dot on the error much like suggestions on missing namespaces?
Regards
Lee
If you are targeting netcoreapp2.1 you can use the metapackage which will include all of "supported" packages from Microsoft.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/metapackage-app?view=aspnetcore-2.1
So allegedly, the configuration tool for Qt went through some changes, necessary to be able to make more streamlined Qt builds, a.k.a "Qt Lite". However, there doesn't seem to be any documentation about how to use that feature, or at least I don't find any, and looking at the comments from the release announcement, others can't neither.
What's more, the changes are definitely in there, judging by the fact that the configuration that I've been using for the last couple of years fails in a bunch of ways. I am not sure how up-to-date the built in help is, since the last time I tried using it for guidance, it turned out it was largely outdated and contained options that were no longer supported.
So it would be nice if someone could shed some light on what has changed and how, and how to configure for "Lite" builds. And especially on module and feature dependencies, because I think we'd all like to avoid wasting time on builds that will start building despite an improper configuration that omits necessary dependencies just to have it inevitably fail and result in nothing but a waste of time.
Per to the changelog:
The configuration system has been rewritten almost from scratch. This improved the consistency between builds on Unix and Windows, but some subtle unintended behavior changes are also possible. Also, some obsolete options have been entirely removed and will now cause errors.
It is not permissible any more to manually #define QT_NO_
anywhere. Instead, configure's -no-feature-* options must be used.
Note that this does not apply to defines which modify behavior rather
than entirely removing features.
The -no-feature-* option family was integrated with the rest of the
configuration system. Numerous existing features were made optional,
and build problems in various reduced configurations were fixed.
This is an ongoing effort known as "Qt Lite".
Features for -no-feature-* lists are in qtbase\src\corelib\global\qfeatures.txt.
All features are enabled by default.
More information can be found in the Qt Lite Overview Presentation and its slides.
You can also use the new UI Tool which is known as Qt Configuration Tool and which is a part of Qt for Embedded Devices package - see its documentation. The configuration tool is available for commercial Qt customers only at the moment (Qt 5.8).
The changes that are behind my failed configuration:
there is no longer the option to specify whether sql support is built-in or plug-in, so the format is now just -sql-<driver>, the documentation is still not updated and lists the old format - -<option>-sql-<driver>.
the -l option to add a specific library has been removed, which is turning out to be problematic in multiple areas.
Edit: Also, this blog entry just posted on doing lite builds might be useful.
Everything that describes what the new configuration system understands is given in the configure.json files scattered around Qt modules. The configure tool uses these files to build a list of command line arguments it understands.
Without the use of other tools, to learn about Qt features you need to inspect these json files and choose the features/options you wish turned on or off.
Sub Configurations
These act as includes, and refer to the configure.json file in a given folder. E.g. qtbase/configure.json includes qtbase/src/corelib/configure.json, qtbase/src/network/configure.json etc.:
"subconfigs": [
"src/corelib",
"src/network",
[...]
],
Explicit Command Line Options
The commandline/options value lists the configure options a given Qt module understands. These options are separate from the feature system, although they may be used for convenience to provide shorthand aliases that control features. For example, in qtbase/configure.json, we have:
{ "commandline": { "options": { "accessibility": "boolean", [...] }
This command line option controls the identically named accessibility feature. It is more convenient to use than dealing with the feature system's option [-no]-feature-accessibility. The following pairs have identical effects:
-accessibility or -feature-accessibility
-no-accessibility or -no-feature-accessibility
Values:
boolean options are given to configure as -option and -no-option, meaning true and false, respectively.
all other options are given as -option value.
Feature Options
The features value lists the features available in a given module. The features are effectively booleans. They are all enabled by default, subject to passing configuration tests that enable them.
To control a feature foo:
-no-feature-foo disables the feature. E.g. to disable the iconv feature, you'd do configure -no-feature-iconv [...].
-feature-foo enables the feature and ensures that it is available. This will cause an error if a configuration test for the feature fails. It's useful in build systems that build a particularly configured Qt along with your application: it ensures that the features your code depends on will be available.
Failing Builds
Generally speaking, no matter what combination of feature selections you provide, if configure doesn't fail, the build is supposed to succeed.
we'd all like to avoid wasting time on builds that will start building despite an improper configuration
The configure tool will detect any invalid configurations. If configure succeeds yet the build fails, it's a Qt bug and you should report it.
For now i'm working on complicated Qt project and trying to eliminate many of warnings which appears when i'm trying to build project with using of different compilers (gcc,clang,msvc). Full rebuild of project takes up a long time.
Is there a some tool or maybe a artful approach to rebuild only modules that has warnings on previous build?
I think it might be reached by deleting (or outdating) those modules. Thus Make utility can rebuild them for me.
As the earlier comment say, only do a normal build. Anything that didn't compile last time will now compile. This of cause requires that you set a compiler flag to treat warnings as error or the compiler will create object files even though there are warnings. And the above strategy will fail.
I am trying to compile a Qt Library Project to use its DLL as a plugin of my Main Application.
I've come across this particular error and I cannot seem to get past it, no matter what I try.
I believe cluttering the question with code tags is pointless when I can just provide you with the "working issue" (for lack of better wording).
This is a link to both projects. The main application AND the plugin I am currently testing on.
(please remember to modify the path in the Application project of the dll. I am using absolute path, which will most likely never be the same one you will use. I used absolute paths to make sure the problem was unrelated to finding the file itself)
So far I've checked:
My Qt version is, indeed, 4.8.2. Built with VS2010 Command Prompt.
As far as I understood the documentation, my code (particularly the APlugin project) follows the documentation instructions word by word. There's some space for human error, but I believe I got it right. as specified here(The Lower-Level API: Extending Qt Applications)
I am able to generate other QPluginLoader::errorString() errors (for example, using an invalid path to the .dll file will return a "file not found" error). Thus diminishing the margin of error in its use.
As of today, Google results are, at best, cryptic and/or do not apply to my current context of development (I am on VS2010, Win7 N Ultimate, Qt 4.8.2)
I believe it's better that I provided projects where the issue is reproducible, instead of just cluttering the question with code, but if you think I still should copy-paste my code, let me know and I will provide it explicitely in the question.
The only thing I am able to provide so far is that, albet I don't use a .pro file, I shouldn't need it, because my application will be windows exclusive, and the vcproj file already contains that data.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.