I've spent two whole days trying to create an initial migration for the database of my project. This is so fustrating. Each preview version of the docs points towards different directions, and there're a lot of unclosed issues flying arround for a while.
My project is an AspNetCore application running on the full framework (net462) although I think I've tryed every combination of preview versions, even the workarounds proposed on this issue: EF Tools 1.1.0-preview4 Unrecognized option '--config' or in this one: https://github.com/aspnet/EntityFramework/issues/7083 but neither work.
This is an abstract of my project.json with the relevant parts:
{
"version": "1.0.0-*",
"buildOptions": {
"platform": "x86",
"debugType": "full",
"preserveCompilationContext": true,
"emitEntryPoint": true
},
"dependencies": {
....
"Microsoft.EntityFrameworkCore": "1.1.0",
"Microsoft.EntityFrameworkCore.Design": "1.1.0",
"Microsoft.EntityFrameworkCore.SqlServer": "1.1.0",
"Microsoft.EntityFrameworkCore.SqlServer.Design": "1.1.0",
....
},
"tools": {
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.1.0-preview4-final",
"Microsoft.EntityFrameworkCore.Tools.DotNet": "1.1.0-preview4-final"
},
"frameworks": {
"net462": {
}
},
...
}
In my case the proposed workarounds don't work, neither using the nightly builds nor downgrading the tools to 1.0.0-preview3.
If I use the 1.1.0-preview4-final version of the tools I hit this error:
Unrecognized option --config
If I use the nightly builds I get this one, wich is somehow absurd, as my app has only one project and is not a dll (it has also emitEntryPoint:true set)
Could not load assembly 'Sales'. Ensure it is referenced by the startup project 'Sales'
But this is my favourite one, when I downgrade to the 1.0.0-preview3-final of the tools I get this surrealistic one:
error: Package Microsoft.EntityFrameworkCore.Tools.DotNet 1.0.0-preview3-final is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Microsoft.EntityFrameworkCore.Tools.DotNet 1.0.0-preview3-final supports: netcoreapp1.0 (.NETCoreApp,Version=v1.0)
I had to read it five times to get sure that in the second sentence was telling just the opposite of the first one... It seems a joke!
Furthermore, commands are not working on the PMC anymore, no matter wich version of the tools I install, no matter if I restore the packages and if I restart the computer...
I'm getting crazy with so many versions of everything and I only want to create a migration, it doesn't matter wich version of the tools I have to use... Is there a valid configuration nowadays or am I trying something imposible?
Has anybody been able to create migrations within an asp.net core application targeting the full .net framework (net462) with ANY version of the ef tooling?
If so, HOW?
EDIT:
After targeting the project to .netcoreapp1.0 and removing the incompatible references now I hit this error:
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\1.0.1'
What's happening here??? I'm really tired of .net Core, and it's still in it's first version. I've suffered a lot of issues like this while it was in beta, but now things are supposed to be stable... They have changed twenty times everything that can be changed, APIs, assembly names, namespaces, package names, conventions... Now let's wait for the preview5, 6 or 25 of the tooling and maybe by the year 2035 EF Core will have appropiate tools and procedures, meanwhile I damn a million time my decission of betting for this technology!
EDIT 2:
As per comments global.json may be relevant:
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview2-1-003177"
}
}
and to add that the 1.0.0-preview2-1-003177 folder exists and is the only one in C:\Program Files (x86)\dotnet\sdk\ and C:\Program Files\dotnet\sdk\
I hate to answer my own question, but I suppose that not too much people will go into this alley... So for those who are struggling with a similar problem I'll tell that mine came from this configuration on project.json:
...
"buildOptions": {
"platform": "x86", <- THIS!!!
"debugType": "portable",
"preserveCompilationContext": true,
"emitEntryPoint": true
},
after removing the "platform" key, migrations started to work again...
I'm not really sure when did I introduced that setting, since I didn't try to create migrations before upgrading to the version 1.1 of the .NET Core SDK. Maybe it was copied from one of the examples on internet, maybe it was from a previous version, I don't know, but that has turned me crazy for days, I hope it helps somebody outthere.
Related
Today I first started programming with Kotlin in VScode. I installed the Kotlin plugin (which as I understood this plugin should provide autocomplete feature), but strangely when I start writing code, the autocompletion doesn't work.
This is in continuation of another problem I faced today with the above plugin that presented an error described here, that after taking the steps suggested here the error disappeared and it seems to be resolved.
But still when I write code I don't get autocompletion.
I also saw on the plugin page (in the Debugging §Setup section) the following instruction:
Open the launch.json file in your project and invoke code completion to create a new launch configuration (or select Add Configuration... in the debug tab)
I don't know if this is what should solve my problem, anyway, this is my launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch kotlin script",
"type": "kotlin",
"projectRoot": "${workspaceFolder}",
"mainClass": "${workspaceFolder}/MainKt.main",
"request": "launch",
}
]
}
If there is a special configuration that needs to be set in launch.json, then I don't know what exactly needs to be there for it to work.
The react-script uses typescript-eslint internally which trows warnings/error and you see it in the terminal where the app is running.
I did create react app with create-react-app --typescript and did set up a tslint.json as follow:
{
"defaultSeverity": "error",
"extends": [
"tslint:recommended",
"tslint-react",
"tslint-eslint-rules",
"tslint-plugin-prettier",
"tslint-config-prettier"
],
"jsRules": {},
"linterOptions": {
"exclude": ["node_modules", "dist", "build", "src/serviceWorker.ts"]
},
"rules": {
"prettier": [true, "./.prettierrc"]
},
"rulesDirectory": []
}
and a lint check script like "lint": "tslint -p tsconfig.json -c tslint.json 'src/**/*.{ts,tsx}'" in package.json.
But not all typescript-eslint from react-script is covered by tslint and the lint script passes while there exists some warning.
Should I completely dump the usage of tslint and go for eslint? If so can someone provide a snippet for the settings?
Or if Tslint has any plan to be update and cover all those warnings from typescript-eslint
Perhaps you could adjust your tslint configuration to get those warning it missed, but I don't think it is worth it.
For starters, as you note CRA has switched to eslint-typescript, and I think it is easier to just use the one officially supported linter rather then using both the old and the new.
Also, tslint is formally deprecated in favour of eslint-typescript so you are swimming against the stream and I doubt there will be updates. You might be able to get tslint to work as you want now, but probably not for the lifetime of your app.
The switch to eslint-typescript was announced almost a year ago and now that the major projects like CRA have also switched I think that early issues are resolved and it is time for all new projects to use it.
I have npm version 6 installed on my machine. I have the following content in package-lock.json:
{
"name": "Project",
"version": "0.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"package1": {
"version": "0.1.2"
},
"package2": {
"version": "0.2.2"
}
}
}
Whenever I am running npm install it's updating my package-lock.json and new contact is like:
{
"name": "Project",
"version": "0.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"package1": {
"version": "^0.1.2"
},
"package2": {
"version": "~0.2.2"
}
}
}
I am expecting to not add ~ tild or cap ^ into the version of package-lock. I am not even adding or removing any package before npm install. Lock file is very big so it's hard to maintain changes manually.
What is the problem? How should I install new packages without affecting old versions?
As per my understanding and whatever I searched on this,I can able to say that,this(package-lock.json) behavior is refactor to make traceability of dependencies easier, even if getting some large lock file diffs in the meantime is not ideal.
package-lock.json should be the tool and mechanism what is responsible to keep everything consistent, so the trust in it is unavoidable and necessary.
Documentation
package-lock.json describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
For example, package.json is:
...
"glamor": "^2.10.00"
...
In package-lock, there are links to specific versions, for example, https://registry.npmjs.org/glamor /-/glamor-2.20.40.tgz
The change only touched the format of the require description.
It was:
"requires": {
"glamor": "2.20.40"
}
Became:
"requires": {
"glamor": "^2.0.0"
}
Semver was not broken (2.20.40 is still matching to ^2.0.0), and the links remained in place
When the package version is updated, the package will still be taken from the link file (there is an old version of the package)
To update the link in the lock file, you must either change package.json or make npm update. For more reference npm issues
More explanation on this:
Let's say that you use pinned versions of dependencies 'aaa', 'bbb' and 'ccc'. Let's say they each depend on 'zzz' like so:
aaa depends on zzz#^1.0.0
bbb depends on zzz#^1.1.0
ccc depends on zzz#^1.0.1
i.e. all three of them depend on a range of zzz, and not an exact version.
And let's say that the latest version of zzz is 1.5.0.
Both before and after this change, it's pretty obvious that the resolved version of zzz should be 1.5.0, so the only difference is how the package-lock.json is structured and documents this sub-dependency.
Before, the lock file would show that all three of them depend on zzz#1.5.0, and the resolved version of z is 1.5.0.
Now, it documents the actual "original" dependency versions (e.g. ^1.0.0, ^1.1.0, etc) for each dependency, but still shows the resolved version of z as 1.5.0.
Then consider what happens when zzz#1.5.1 is released:
Before, the lock file would need to update from z#1.5.0 to z#1.5.1 in all four places.
Now, the lock file only needs to update the resolved version of z to 1.5.1 while the dependencies can keep the ^1.0.0, ^1.1.0, and ^1.0.1 because they haven't changed.
As I mentioned previously in the thread, you still get the exact same node_modules in both cases. The advantages of the new approach are:
You get to see what the dependencies actually require (e.g. a range, and not an exact version). before, you could not tell if aaa actually required exactly zzz#1.5.0 or that it was instead zzz#^1.0.0.
Instead of four lines changing in the lock file, you get only one. It's less churn, and it's more clear what's happened.
As an aside, yarn uses a similar concept with yarn.lock. e.g. here's an example where #sindresorhus/is is pinned, but it's sub-dependency symbol-observable is not:
"#sindresorhus/is#0.10.0":
version "0.10.0"
resolved "https://registry.yarnpkg.com/#sindresorhus/is/-/is-0.10.0.tgz#f42dd6a9d12cd79fa6f53b27cf5bea3a30d2cafa"
dependencies:
symbol-observable "^1.2.0"
I need help with my TFS 2015, I able to run build and publish in Visual Studio 2015 and when I create a build it in TFS 2015, my jquery is not completely built.
my setup in Command Line
Tool : C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\npm\bower.cmd
Arguments : install jquery
Build log
Everything works fine except the jquery only a few files and folders were created compared to build from in VS 2015.
Please let me know where I did wrongly.
Try the solution in this case ECONFLICT Unable to find suitable version for jquery Foundation:
Use resolutions in your bower.json file. For example:
{
"name": "refactor",
"private": true,
"dependencies": {
"jquery": "~1.11.1",
"raphael": "1.3.x",
"font-awesome": "~4.3.0",
"foundation": "x"
},
"resolutions": {
"jquery": "~1.11.1"
}
}
This will force bower to use that specific version of jQuery.
Environment: Ubuntu 16.04, .NET Core SDK Preview 2.0.0 (006497), VSC 1.14.2
Things used to work fine under .net core 1. Now, I have upgraded my system to .net core 2.
From the command line, I created a new project and ran it:
$ dotnet new mvc
$ dotnet run
The webpage works as expected.
Now, I open the folder in VSC and tried to debug the app. First time, VCS helps create launch.json and tasks.json. Here is my tasks.json contents:
"version": "2.0.0",
"tasks": [
{
"taskName": "build",
"command": "dotnet",
"type": "shell",
"group": "build",
"presentation": {
"reveal": "silent"
},
"problemMatcher": "$msCompile"
}
]
}
In the terminal view, I see that VCS tries to run the build command as dotnet <. This throws an error that preLaunchTask "build" exited with error code 129.
I tried to fix this by adding args: ["build"] to the task. This seems to fix the build but I now get another error about launch.json not being configured properly.
Wondering if there is some step that I simply missed. Regards.
The answer was provided by mvermef in his comment. I am just adding a new post here so I can mark it as an answer.
The problems with VSC are explained at https://github.com/dotnet/core/blob/master/release-notes/2.0/2.0.0-preview2-known-issues.md. The most important thing is that you remove your existing C# extension and replace it with the latest beta version. Now, if you create a new project from the command line and load it in VSC, you should be able to debug it.