.NET Core 1.0.4 and 1.1.1 #532
Comments
|
When running the install steps from https://github.com/dotnet/core/blob/master/release-notes/download-archives/1.1.1-download.md: I get the following error: Doing |
|
Seems that it should be sudo apt-get install dotnet-dev-1.0.1 I'll submit a pull request. Edit: Submitted it, let me know if I'm horribly wrong. #534 |
|
@leecow @kendrahavens is possible to add the f# info from wiki to blog post? https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-1.0.1 that add some important info and workarounds (like how fix intellisense 😄 ). |
|
On Ubuntu 16.10, with dotnet SDK 1.1.1 (same happening with 1.0.4) when doing (lang is irrelevant): I get: This worked fine previously with RC4. |
|
CC @mlorbetske |
|
@kontomondo could you zip up the directory at ~/.templateengine and mail it to me at mlorbe@microsoft.com please? After zipping it up and moving it out of that directory, please try running dotnet new --debug:reinit, after that runs things should return to working normally |
|
@mlorbetske I see what the problem is now -- it got initialised in one directory and then I moved it to another, but the template engine settings still has the old "mount points", so it essentially wasn't able to find the files. It should probably check whether dotnet's path has changed and if so, re-initialise the template engine data ? (or simply when files are not found, attempt to re-init maybe) |
|
@enricosada After creating a sample F# application, Note that a C# sample application restores builds and runs properly. This happens for the Ubuntu 16.10 SDK 1.1 download: https://go.microsoft.com/fwlink/?LinkID=843446 |
|
@kontomondo we agree, we're actively working on handling these sorts of scenarios |
|
@kontomondo abouut f#, can you open an issue in https://github.com/dotnet/netcorecli-fsc/issues ? |
|
@kontomondo no need to add issue, probably is the same as dotnet/netcorecli-fsc#91 . check that issue for status updates |
|
@enricosada The F# link was added to the post earlier. :) |
|
@kendrahavens i cannot find it in that blog post now, but thx anyway. |
|
@enricosada Hmm, I can't find it either. |
|
@enricosada - I added the fsharp wiki link to release notes for 1.0.4 and 1.1.1 |
|
When can we expect 1.1.1 to be pushed to the repositories? I upgraded my project to 1.1.1 but Ubuntu 10.4 is still on 1.1.0. |
|
@yesman85 - I've confirmed that the 1.0.1 SDK and 1.1.1 Runtime are on the feed using for Ubuntu 16.04 and 16.10. You should be able to |
|
@leecow very odd, I tried multiple times and even with a clean install but it stays on 1.1.1. When I do an install: It looks like it installed "dotnet-sharedframework-microsoft.netcore.app-1.1.1", but is it maybe the tooling that is reporting the wrong version? |
|
@yesman85 - First off, everything looks correct so you're in good shape :-). Second, I apologize for our versioning and the way it's reported is unclear and confusing. When you do an install there are three components which can version independently: host, runtime/shared framework and the SDK. All of these can live side-by-side. Trying to organize and tell a coherent story with all of these versions floating around is proving very difficult. Your apt-get install output indicates the packages included in the 1.0.1 SDK are set up.
Hope that brief explanation is helpful. |
|
We have projects handling XSD, so we previously only use .net core 1.0 full framework, and wait Q3 .net core 2.0. So in this case, since full version can reference .net framework 4.6.1, so we can have part of projects using .net core 1.0, part of 4.6.1, they work well. But after I upgraded to visual studio 2017, it's said the projects are all not compatible with .netcore1.1, does this mean that .net core 1.1 doesn't support full framework? |
|
Hi @leecow , Here are the logs user@user-VirtualBox:~$ sudo apt-get update E: Some index files failed to download. They have been ignored, or old ones used instead. E: Some index files failed to download. They have been ignored, or old ones used instead. I am using ubuntu on VirtualBox |
|
Hi @nikamsshekhar, many of those errors have to do with reaching the ubuntu feeds and not just the dotnet feed so something is definitely amiss. Can you confirm the contents of |
|
A couple of issues with the RedHat installation procedure: OS version: Red Hat Enterprise Linux Server release 7.3 Error messages and then running "sudo scl enable rh-dotnetcore11 bash" takes me to root user (?), but the following command still cannot find the dotnet: If I run the 'scl' command without sudo, then the current user path recognizes where the dotnet is installed (/opt/rh/rh-dotnetcore11/root/usr/bin/dotnet), however this doesn't seem to be persistent, as after a re-login, 'which dotnet' returns the following: |
|
I followed instruction : https://www.microsoft.com/net/core#linuxredhat to install .Net Core. Seems I need to enable dotnet with "scl enable rh-dotnetcore11 bash" whenever I started a new bash session. Is this behavior intended? |
@richlander @kendrahavens are the instructions correct? |
|
Hey @EmmaZhu
Yes. There's a few reasons for use-via- Another reason is that without SCL, we would be tied to RHEL's release cycle and not be able to get updates out within days or weeks of upstream release. We would be doing non-security updates at 6 month (or longer) cycles.
Please feel free to file bugs at bugzilla.redhat.com. User pains help us direct effort and weigh options. It's kind of hard for us Red Hat folk to monitor all github issues :) |
|
The version of the tooling (1.0.4) and the versions of runtime(s) that it carries (1.1.2 and 1.0.5 in this case) are not tied together, as they have a different release cadence. For instance, we don't want to rev the runtime because of a tooling bug. |
|
@livarcocc in that case we should mention it in the docs, something like "don't worry about not matching numbers". I am confused - I thought it is a bug, and I am on the team :( |
|
@karelz I tried documenting it once: https://stackoverflow.com/documentation/.net-core/9592/components-and-versioning-in-net-core (copy on my blog). Is this something that might be useful as part of .NET Core 1.x docs? |
|
@omajid @karelz @livarcocc Thanks for the responses. It is clear to me now from below snip, but it isn't super obvious that the latest SDK 1.0.4 includes both LTS and current runtimes.
thanks |
|
@omajid it is not about 'ad-on' docs. IMO it should be crystal clear from the main docs -- installation docs in this case. Additional documentation is just too late. The confusion has been already seeded. @stanuku see https://github.com/dotnet/cli/issues/3773 for discussion about |
|
@karelz: Thanks The discussion https://github.com/dotnet/cli/issues/3773, basically had a disappointing end in spite of many valid concerns and suggestions. I've been a .NET dev for over a decade (since 2.0) and consider myself a decent one at it. But, never before I'm subjected to such confusion and uncertainty. I'm having a hard time wrapping my head around this stuff. I'm not sure if I'm prepared to answer questions that would follow when I propose the adoption of .NET Core in new projects at my work. And also when I try to guide and mentor mid and junior level developers on this stuff. Let alone the issues I might face communicating to the server and IT teams about the bits that I would need them to install on build and hosting servers. I hope common sense would prevail. One of the perils of the "open source" perhaps (Not that I'm against it, actually I love it when it is managed well and at a smaller scale. I don't expect everyone here to agree with me) however, exposing all the moving parts to a developer who could care less about the CLI/SDK etc etc and just wants to know a single one version number that can be used to pick up in the Target framework drop down in Visual Studio for example and be done with it and move on to more important business problems. |
With .Net Framework, you use Visual Studio 2017, MSBuild 15 and C# 7 to develop and build your applications and .Net Framework 4.7 to run them. With .Net Core, you use Visual Studio 2017, MSBuild 15, C# 7 and .Net Core SDK 1.0 to develop and build your applications and .Net Core 1.1 to run them. It is more complicated and the naming can be confusing (since it's easy to overlook the "SDK" part), but I'm not sure it's as bad as you make it sound.
Do you have any specific suggestions for how the tooling can be improved?
There were huge changes in the past (dnx → dotnet, project.json → csproj), but as far as I know, the only somewhat big change that's coming is .Net Standard 2.0. So I wouldn't exactly call it "fluid". And if you really need "tons of hours" to understand that .Net Core and .Net Core SDK are distinct and versioned separately, then I think something is very wrong. (Maybe it's the documentation?) |
|
@svick Thanks for your response (A disclaimer: I'm a very loyal .NET developer most of my professional career. I made and still making my living because of it. So far, I'm glad I didn't have to go through the constant catch up and churn that you find in the other popular and competing stacks) Here are my thoughts/concerns:
Some suggestions/comments:
NOTE: I'm super excited about the .NET Core and ASP.NET Core but it is so far just limited to my personal projects and a couple simple cookie cutter web applications at work. I don't feel too confident yet to start building a case for a wider adoption at my work place at a bigger scale especially, training the devs. Given the management has bigger problems to solve and other priority and don't really see a pressing need to migrate. I'll have to sit out and watch .NET Standard 2.0 unfold and target .NET 4.6.1 till then. Sometimes I wonder who is MS targeting with the .NET Core movement. |
.Net Core SDK 1.0 was released this February. I don't think it's fair to complain about churn before that.
I don't know anything about future plans for EF or EF Core. But even if EF Core is the future, then you can still stay on .Net Framework, since EF Core is a .Net Standard library and .Net Framework does support .Net Standard. (And that's not something that's new with .Net Standard 2.0.)
If any of the unique features of .Net Core (not just it being cross-platform, but also e.g. different deployment strategies) do not appeal enough to you, then you should not migrate, possibly ever. Even the documentation recommends not to migrate existing .Net Framework applications.
Isn't it like that already? If you install .Net Core tooling for VS from the VS installer, you don't have to care about any .Net Core SDK version, no? The VS-specific section of the .Net Core getting started page also does not mention any SDK versions. |
I think it is, especially given .NET Core 1.0 was released last year. I - and many others - had no idea SDK and non-SDK were different components, were being developed independently and were versioned separately. And I was talking to folks working on .NET Core every week... |
|
@svick: Again I'm not debating on the decisions, but giving an outside perspective. This perspective is from people like me who would ultimately take the result of the efforts of people like you (within and outside MS) to a bigger picture, people who would utilize your product to build bigger things, solve real problems and generate revenue and act as ambassadors of the .NET brand. My main point is, did MS have .NET Standard 2.0 in mind all along? if so, then the pain and rough ride for the early adopters could have been mitigated with proper and timely communication and guidance. If not, and if .NET Standard 2.0 just evolved based on the feedback, then it makes me feel a bit uncertain of what else could change in the future (for a brief period just before the BUILD 2017, there was confusion on .NET Core 2.0 not supporting .NET Standard 2.0. The big guns at MS had to do the damage control later and clear the confusion. I suspect they must have debated about it internally and retracted based on the feedback)
Not just the SDK I was referring to the other components of the .NET Core. Same sentiment as @omajid has expressed.
Unless I'm missing something, the VS 2017 still doesn't show what versions I'm getting or targeting from the project creation dialogs. Although, I don't mind editing the project files and changing the TFMs and other details, not everyone would prefer to do that. VS2017 is promising but, I'm suspecting we have good couple of iterations of .NET Core/Standard i.e. 2.*, 3.0 and VS 2018, 2019. Before, we get there where we want to be. I can't wait for it. But will watch cautiously. I had bore the brunt of early adoption in 2016 already. Thanks |
As far as I know, they didn't. It came from the acquisition of Xamarin and their realization that the best way to support .Net Framework, .Net Core and Xamarin/Mono all at the same time was to expand .Net Standard.
To clarify, the confusion was about ASP.NET Core 2.0 not supporting .Net Standard 2.0, and thus also not being able to run on .Net Framework.
Yes, it doesn't. But you can change it from the project properties page, you don't have to edit the project file.
I'd say that in 2016, you were a very early adopter: i.e. not everything was even expected to work. In 2017, you're just an early adopter: everything should work, but the experience might not be quite polished yet. So waiting some more before switching to .Net Core sounds like a reasonable business decision to me. (Even if part of me wishes everyone would always work from |
You're right, my concern still applies though.
Yes, you still wouldn't know what the runtime version (major.minor.patch) is. Shouldn't we need to know? |
|
Closing. .NET Core 1.0.5 and 1.1.2 have now shipped. See #622 |
Thanks for your interest in .NET Core.
You can read about .NET Core 1.0.4 and 1.1.1 in the .NET blog announcement.
Please report any issues you find with .NET Core 1.0.4 and 1.1.1 here, either responding to this issue or creating a new issue.
Please include the following information plus any other info that you think is relevant:
OS version
Repro steps
Repro code (if you can share it / is relevant)
Error messages
Whether this worked before
Method of installing .NET Core
Please note that this repo (dotnet/core) is not for filing product issues. Here are some repos where you can file an issue:
dotnet/cli - for CLI tools and questions
dotnet/corefx - for API issues and questions
dotnet/coreclr - for runtime issues
nuget/home - for NuGet questions and issues
The text was updated successfully, but these errors were encountered: