Django/Visual Studio Tutorial - objects method error - django

I'm working through the Django Tutorial (here). I'm using visual studio on a Mac and VS keeps showing an error on this code:
latest_question_list = Question.objects.order_by('-pub_date')[:5]
The error reads Class 'Question' has no 'objects' member.
The example builds a Questions Class which in fact doesn't directly have an objects member, but the code runs fine and I think that there is a built in member within Django that has objects.
So that leads me to believe that the visual studio debugger is raising an error that doesn't actually exist.
Is there a way to fix this?
I've looked through preferences/setting and under extensions to see if there is a plugin or setting reference that could be made to Django to clear the error within Visual Studio - I didn't see anything.

That is not error, just a warning from the Visual Studio Code. objects is a Manager instance which is added to our model classes dynamically by django. When VS Code checks the class declaration, it do not found objects declaration there, so warns us about a possible error.
In, Visual Studio code, python extension uses pylint as default linter.
To work it properly you can install pylint locally as:
pip install pylint
Or, you can also disable linting by configuring the following property in either one of (User or Workspace settings file) as follows:
"python.linting.enabled": false
For django projects, you can customize the pylint plugin by modifying the User or Workspace settings as follows:
"python.linting.pylintArgs": ["--load-plugins", "pylint_django"]

For anyone who gets "Expected comma" error in User Settings, put comma to previous argument and after this one "python.linting.pylintArgs": ["--load-plugins", "pylint_django"]
Must be like this:
{
"python.pythonPath": "C:\\Program Files (x86)\\Python37-32\\python.exe",
"python.linting.pylintEnabled": true,
"python.linting.enabled": true,
"[python]": {
},
"python.linting.pylintArgs": [
"--load-plugins", "pylint_django"
],
}

Related

Why default build tasks in vs code runs in powershell instead of the default terminal selected? [duplicate]

When I woke up this morning and launched VSCode my default terminal on launch, and when running tasks is now powershell, instead of Git Bash. I am on windows. I have tried changing the settings.json to no avail. Is there something I'm missing?
{
"workbench.startupEditor": "newUntitledFile",
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
"[javascript]": {
"editor.defaultFormatter": "rvest.vs-code-prettier-eslint"
},
"aws.samcli.location": "C:\\Users\\king\\AppData\\Roaming\\npm\\sam.exe",
"typescript.updateImportsOnFileMove.enabled": "always",
"[html]": {
"editor.defaultFormatter": "vscode.html-language-features"
},
"editor.formatOnSave": true,
"editor.formatOnPaste": true,
"javascript.updateImportsOnFileMove.enabled": "always",
"explorer.confirmDragAndDrop": false,
"diffEditor.maxComputationTime": 0,
"extensions.ignoreRecommendations": true,
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.renderControlCharacters": true,
"[jsonc]": {
"editor.quickSuggestions": {
"strings": true
},
"editor.suggest.insertMode": "replace"
},
"window.zoomLevel": 0,
"editor.accessibilitySupport": "off",
"workbench.editor.untitled.hint": "hidden",
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.external.windowsExec": "C:\\Program Files\\Git\\bin\\bash.exe",
"terminal.explorerKind": "external",
"terminal.integrated.automationShell.linux": ""
}
I found this related SO post making the default powershell, but I didn't see anything that was incorrect about my setting...especially because my goal is the opposite- to stop Powershell!
Update: Version v1.60.0 had a bug. Upgrade to v1.60.1 or higher for a fix.
The bug manifested in the following symptoms:
The Open in Integrated Terminal shortcut-menu command in the Explorer pane's shortcut always uses the built-in default shell (PowerShell on Windows), ignoring the configured one.
The same goes for running tasks (with or without a separate terminal.integrated.automationShell.* setting).
Also, if a given folder or workspace happened to have an integrated terminal open when quitting Visual Studio Code, the shell that is launched when the integrated terminal automatically reopens the next time is again the built-in default shell, not the configured one. By contrast, if reopening doesn't auto-open the integrated terminal, opening it manually does respect the configured default shell, and so does manually creating another shell instance later.
See GitHub issue #132150
The following information turned out to be unrelated to the bug, but is hopefully still useful general information about Visual Studio Code's recent change in how shells for the integrated terminal are configured:
Migrating from the legacy default shell settings to shell profiles:
Recently, the "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings were deprecated and replaced with a more flexible model that allows defining multiple shells to select from, via so-called shell profiles, optionally defined in setting "terminal.integrated.profiles.*", with an associated mandatory "terminal.integrated.defaultProfile.*" setting referencing the name of the profile to use by default - which may be an explicitly defined custom profile or one of the built-in, platform-appropriate default profiles.
Note: * in the setting names above represents the appropriate platform identifier, namely windows, linux, or osx (macOS).
As of v1.60.1, if legacy "terminal.integrated.shell.*" settings are also present, the new settings take precedence (even though the tooltip when editing "terminal.integrated.shell.*" in settings.json suggests that this change is yet to come).
In the absence of both settings, Visual Studio Code's built-in default shell is used, which on Windows is PowerShell,[1] and on Unix-like platforms the user's default shell, as specified in the SHELL environment variable.
Recent Visual Studio Code versions, starting before v1.60 - seemingly as one-time opportunity - displayed a prompt offering to migrate the deprecated settings to the new ones.
Accepting the migration results in the following:
Creation of setting "terminal.integrated.shell.*" containing a custom shell profile derived from the values of legacy settings "terminal.integrated.shell.*" and, if present, "terminal.integrated.shellArgs.*"; that custom profile's name has the suffix (migrated)
Creation of setting terminal.integrated.defaultProfile.* whose value is the migrated profile's name, making it the default shell.
Removal of legacy settings "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*"
If you decline the migration, you can later effectively perform it by re-choosing the default shell, as described below.
Note: The new "terminal.integrated.defaultProfile.*" setting that is created in the process then effectively overrides the legacy "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings, but the latter won't be removed automatically. To avoid confusion, it's best to remove them from settings.json manually.
Choose the default shell profile to use in order to (re)specify the default shell:
Click on the down-arrow part of the shell-selector icon () on the right side of the integrated terminal, select Select Default Profile, which presents a list of the defined profiles to select the default from - in the absence of explicitly defined profiles, standard profiles are offered (see below).
This translates into a terminal.integrated.defaultProfile.* setting in settings.json, whose value is the name of the chosen shell profile - which may be the name of a built-in profile or one of the ones explicitly defined in "terminal.integrated.profiles.*"
Note: This shell is by default also used for tasks (defined in tasks.json), but that can be overridden with a "terminal.integrated.automationShell.*" setting pointing to the executable of an alternative shell.
Optionally, in your settings.json file, you may create a platform-appropriate terminal.integrated.profiles.* setting with shell profiles of interest:
Note: Even if your settings.json contains no (platform-appropriate) "terminal.integrated.profiles.*" setting, Visual Studio code has built-in standard profiles it knows of and offers them for selection when choosing the default shell.
These standard profiles are a mix of shells that come with the host platform as well as some that Visual Studio detects dynamically on a given system, such as Git Bash on Windows.
To create the standard profiles explicitly, do the following:
Note: You may choose to do this in order to customize the standard profiles. However, if your intent is merely to add custom profiles - see this answer for an example - it isn't necessary to create the standard profiles inside the "terminal.integrated.profiles.*" setting, because Visual Studio Code knows about them even if not explicitly defined.
Via File > Preferences > Settings (Ctrl-,), search for profiles and click on Edit in settings.json below the platform-appropriate Terminal > Integrated > Profiles > * setting; this will open settings.json for editing, with the standard profiles added; simply saving the file is sufficient.
Note: If the "terminal.integrated.profiles.*" setting shown doesn't contain the expected, platform-appropriate standard profiles, a setting by that name may already be present; to force creation of the standard profiles, remove or comment out the existing setting and save the file, then try again.
On Windows, you'll end up with something like the following:
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
"${env:windir}\\Sysnative\\cmd.exe",
"${env:windir}\\System32\\cmd.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
}
}
The answer you link to in your question, which provides an overview of the various types of shells used in Visual Studio Code, has been updated to reflect the information about the new shell profiles.
[1] Note: If a PowerShell (Core) v6+ installation is found, it takes precedence over the built-in Windows PowerShell version.
Edit:1
Note: Now this bug has been fixed by VSCode. Just update your VSCode to the latest version. (17-Sep-2021)
I have a temporary solution.
First paste this code in settings.json and save
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.integrated.profiles.windows": {
"C:\\Program Files\\Git\\bin\\bash.exe": {
"path": "",
"args": []
}
},
Before closing VSCode select Output instead of Terminal
Now you can open VSCode
After VSCode is loaded, you need to click on Terminal. After this you will now see bash.
Select output before whenever you close VSCode.
Reference: VSCode is suddenly defaulting to PowerShell for integrated terminal instead of $Bash in Windows
Note: This is not an solution. I shared this because maybe it can save you from getting disappointed.
This is my first post, if there is any mistake please let me know so that I can correct it.
You can always download and install previous releases from the official website https://code.visualstudio.com/updates/v1_59 (currently at the top).
As version 1.60 was bugged, v1.59 is a good candidate.
Disable automatic updates
Explained here.
Open User Settings File > Preferences > Settings.
Add "update.mode": "none" to your settings.
Install older version
Afterwards you can just overwrite current version with the installation of downloaded version.
Note: Wait for next version to fix it, so remember you had automatic update disabled!
I have same problem but I try run command prompt. I fix it by adding to ...\Code\User\settings.json
"terminal.integrated.automationShell.windows": "cmd.exe",
This could be related to issue 138999 which will add a mitigation/enhancement to VSCode 1.70 (July 2022) with PR 154290 and commit 91b82c0
increase barrier for available profiles to be ready
Wait up to 20 seconds for profiles to be ready so it's assured that we know the actual default terminal before launching the first terminal.
This isn't expected to ever take this long.
For VSCode with synchronized user settings, the profile might take more time than expected to fully load, hence the advantage of that workaround.
Simply replaced the CMD by Git Bash :-) in the settings.json
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
//"${env:windir}\\Sysnative\\cmd.exe",
//"${env:windir}\\System32\\cmd.exe"
"C:\\PrivateProgramms\\Git\\bin\\bash.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
//"path": [ "C:\\PrivateProgramms\\Git\\bin\\bash.exe" ],
//"args": [],
//"icon": "terminal-cmd"
}
},
"terminal.integrated.defaultProfile.windows": "Command Prompt"

why I can not create a VC++ empty project on my windows using vs 2015 ,vs2017,vs2019

in VS 2015, there is a warning dialog 'null' is null or is not object when i try to create a VC++ project:
then i get another warning:
error from HRESULT:800A138F
in VS 2019 i got the warning:
Object reference not set to an instance of an object,
You could try steps below to resolve this issue:
1.Windows+R and enter regedit to open Registry Editor, make sure the value data of Enabled key is set to zero.
We can find the key here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy
2.Restart VS to check if the issue goes away, if it persists, close all vs instances and delete all folders under path: C:\Users\xxx\AppData\Local\Microsoft\VisualStudio . It will clean all VS cache to reset the VS settings.
Note: AppData is a hidden folder.

Visual Studio 2017 JavaScript Language Service has been disabled

While editing JavaScript source files in Visaul Studio 2017, the following error keeps occuring:
The JavaScript language service has been disabled for the following project(s): ...
Even if I disable the JavaScript language service entirely, the error keeps occuring. Why is this happening and how do I stop this error message from displaying all the time? Can I disable the JavaScript language service entirely?
The solution to the problem was simply to use a tsconfig.json file, even though there were only JavaScript files in my solution.
I've just used the following tsconfig.json file in the root of the project:
{
  "compileOnSave": true,
 "compilerOptions": {
    "noImplicitAny": false,
    "noEmitOnError": true,
    "sourceMap": true,
    "target": "es2015",
    "module": "amd",
    "allowJs": false,
    "allowSyntheticDefaultImports": true
  },
  "exclude": [
    "lib",
    "node_modules"
  ]
}
open 'developer command line tool for visual studio'. run :
devenv.exe /resetuserdata

Visual Studio 2015: C++ code analysis error C1253, unable to load model file 'res://mspft140.dll/300'

Visual Studio 2015 Community update 3, trying the C++ code analysis feature. The settings are as follows:
solution properties > code analysis settings > [all configurations] [all platforms] : microsoft native recommended settings
project properties > code analysis > [all configurations] [all platforms] : microsoft native recommended settings
Whenever I run analyze > run code analysis on solution I would always get a c1xx : fatal error C1253: Unable to load model file 'res://mspft140.dll/300'. This happens to every project, new or existing. MSDN is not particularly helpful about this one.
The string is a res protocol, so I checked if the dll mentioned is at its correct location (there are two actually, at c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\ and c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64), and opened them with resedit. Both contain an XML resource named 300, so I don't see any reason for VS being unable to load it. Resetting the settings didn't help, full uninstall and reinstall (half a day wasted) did neither.
I also ran procmon with [Path] [contains] [mspft] filter while running the code analysis in VS, but the file system results are only SUCCESS and FILE LOCKED WITH ONLY READERS, which seems to be ok.
Did anyone experience this error? Does anyone have any surmises about its cause?
Update: After looking thoroughly through many more procmon captures with different filters I found out that cl.exe tries to open this registry key value: HKCR\PROTOCOLS\Handler\res\CLSID. Clearly it looks for the handler of the res protocol mentioned in the error output - and it's not there to be found, while many siblings of res key refer to some valid handlers, for example, http key has CLSID value of {79eac9e2-baf9-11ce-8c82-00aa004ba90b}. I guess that my quest for now is figuring out what that res CLSID is meant to be.
I was right in my assumption about the res protocol handler. The correct HKCR\PROTOCOLS\Handler\res\CLSID value is {3050f3bc-98b5-11cf-bb82-00aa00bdce0b} (which refers to C:\Windows\System32\mshtml.dll). For some reason my registry was missing it; as soon as I added the value, the code analysis started working without errors.
I hope this helps someone, although I believe the bug is extremely rare.

MSB4018 The "ResolveComReference" task failed unexpectedly

I am currently trying to upgrade our c++ mfc solution from visual studio 2010 to a visual studio 2013 solution. When i try to build it i get the error MSB4018 The "ResolveComReference" task failed unexpectedly. I enabled fusion logging and this is what it tells me:
=== Pre-bind state information ===
LOG: DisplayName = System
(Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: System | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
LOG: Initial PrivatePath = NULL
Calling assembly : Microsoft.Build.Tasks.v12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. ===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System/System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System/System.EXE.
I understand that msbuild has been moved, but i dont understand why it is trying to find System.dll in the msbuild path, how can i make it look for it in its proper location?
Edit:
I have now also tried upgrading to visual studio 2012 which worked without bigger problems and I did not run into the same problem. However i noticed that when running devenv /upgrade (with vs2013) it seems to completely change everything under vc++ directories (it stayed unchanged when upgrading to vs2012). Could this have something to do with this issue?
Edit2:
Tried to build the project in vs2013 after upgrading it to 2012 (without running devenv /upgrade), this also didnt work so I guess the problem is not related to that...
After enabling diagonostic build output i found that it was 3 broken COM references in the project that where failing to load. Removing these references solved the building issue. These where only showing up as warnings in vs2010 but resulted in MSB4018 in vs 2013 for some reason.
This is your problem:
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
Fix the base folder in your build system if you really need it to point to another filder. However it would probably be better to redo you build system targeting 2013 instead of patching the 2010 version.