When developing an ASP.NET 5 app, I can install the mono runtime into it via NuGet. For example, the latest to date dnx-mono.1.0.0.rc1-update1.
As far as I've tested, the thing is the actual runtime I'm installing on, for example, Linux via DNVM tool to run ASP.NET apps on it.
If I installed the package into a project, I can't then chose it in project properties, nor I can chose it when publishing into a folder - only Windows clr versions are available.
So what's the point of installing it right into the application project?
Or maybe it is not intended to be installed into a project, but exists solely for DNVM could find and pick it up?
You're right. It is used by DNVM and your application should never reference it directly.
Related
I am trying to build a Blazor Server project that I have cloned from a repo. I am getting the message in the Output window of Visual Studio 2019 that the Shared namespace does not exist. The Shared namespace is created in the Blazor template and was not something I added to the project. This also happens if I create a new project and try to run it. Others on my team are able to clone this repo and run it. I have uninstalled and reinstalled Visual Studio 2019 Enterprise edition and also the Dotnet 3.0.1 framework. The only thing I can think that might be the difference is that I updated my VS 2019 to 16.3.10, but even after uninstalling and reinstalling, I have the same issue. I know I have read some things about mismatching of VS and Dotnet core framework SDK versions causing issues but not sure if this is the case here.
I was able to resolve this issue by rebuilding the project after clearing Nuget Caches.
Path: Tools -> Nuget Package Manager -> General -> Clear all Nuget Cache(s).
I'm getting more and more confused with .NET Core's SDK and runtime versioning, and I doubt I'm the only one. I want to get a few things straight.
I've created an ASP.NET Core application targeting .NET 4.6.1 - it hits 4.6.1 libraries and Net Standard libraries. Recently I made the switch from project.json to csproj as part of the VS2017 rollout. The 1.1.1 runtime came out with SDK 1.0.1 a few weeks ago, which I downloaded (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md).
dotnet --version gives me the correct SDK (1.0.1)
However, typing "dotnet" into cmd I see "Version : 1.1.0". Shouldn't this say 1.1.1? My Programs and Features shows that the 1.1.1 runtime is installed.
Fast forward to hosting my app: I install the latest windows server hosting package to host on IIS according to https://learn.microsoft.com/en-us/aspnet/core/publishing/iis, that is 1.0.4&1.1.1. Installing this on my server installs "Microsoft .NET Core 1.0.4 & 1.1.1 - Windows Server Hosting" and "Microsoft .NET Core 1.0.4 - Runtime". Shouldn't it have also installed the 1.1.1 runtime? It works, so maybe it's not necessary.
Ultimately, my questions are the following:
Does the runtime version matter when targeting .NET 4.6.1 at all?
Is runtime just used to run the AspNetCoreModule for the IIS to kestrel reverse proxy?
Will installing new Windows Hosting packages break existing projects already running on the servers?
Does .Net's netstandard packages (such as MVC) versioning correspond in any way to the runtime version, or is it just regular semantic versioning? The newest versions of most "Microsoft.AspNetCore.X" packages are 1.1.1.
I'm in the same situation, compiling my ASP.NET Core app against the full .NET Framework (4.5.2 in my case) and deploying it on IIS. Hopefully I can help.
When using the full .NET framework, you need to install the SDK on your developper machine to compile, but to deploy it on an IIS server you don't need any .NET Core runtime installed at all. On my IIS server, I just need .NET Framework installed and then I'm installing the "Windows Server Hosting" as suggested here: https://github.com/dotnet/core/blob/master/release-notes/download-archives/1.0.4-download.md with a command line that won't even install any .NET Core on my server:
DotNetCore.1.0.4_1.1.1-WindowsHosting.exe OPT_INSTALL_LTS_REDIST=0 OPT_INSTALL_FTS_REDIST=0
This installation is super quick and is just deploying the minimum amount of files IIS needs to run your .NET Core app, which is mainly the aspnetcore.dll. I don't even have a directory "C:\Program Files\dotnet" (so no runtime or sdk) on my server and my app is working fine.
So, I would say:
no, it doesn't matter, it won't run against any .NET Core runtime
no, AspNetCore.dll is a C++ module (https://github.com/aspnet/AspNetCoreModule)
I don't see how it could break anything
at the moment, when you add a Nuget package in your ASP.NET Core app, its versionning seems quite independant to me, that's why Microsoft is now providing metapackage to help people using the proper set of Nuget package (https://andrewlock.net/what-is-the-microsoft-aspnetcore-metapackage/)
Regarding:
However, typing "dotnet" into cmd I see "Version : 1.1.0". Shouldn't
this say 1.1.1? My Programs and Features shows that the 1.1.1 runtime
is installed.
I'm wondering the same thing and can't figure out where this is coming from, maybe it's just the version of the "dotnet" command line tool that is package with the SDK 1.0.1, but I can't prove it.
I have a small C# WinForms app developed using Visual Studio Community 2015 on Windows 8.1 on a 64-bit computer and targeting .Net Framework 4.5.2 and Any CPU | Prefer 32-bit. (I also tried targeting just x86).
I used NuGet Package Manager to install Entity Framework 6.3.1 and System.Data.SQLite 1.0.101 (which installed System.Data.SQLite, System.Data.SQLite.Core, System.Data.SQLite.EF6, and System.Data.SQLite.Linq), though System.Data.SQLite.Core doesn't show in the project references.
The app runs fine in the VS debugger, but the ClickOnce published version triggers an Unable to load SQLite.Interop.dll exception when installed and run on the same computer.
I don't see any references to SQLite.Interop.dll in Solution Explorer. There are such dlls in both the x86 and x64 Debug folders of the project, but not in the Release folder which is empty. When I try to add a reference to either the x86 or x64 dlls, I get an error saying they could not be added (i.e. inaccessible or not a valid assembly or COM component). All 3 of the SQLite dlls in the project references have Copy Local = true.
I'm guessing the SQLite NuGet install failed to set some project property/reference, but I don't know what that might be, why, and how to get around it. I'm not even sure who's responsible: SQLite, NuGet, Visual Studio, me?
Thanks for any help. Steve
I JUST found a working solution. Read the comment outlined https://github.com/oysteinkrog/SQLite.Net-PCL/issues/158#issuecomment-88163499 <- there
Important piece:
I created new PROJECT folders for x86 and x64. I created the project folders in the project that click-once deploys. That is, the project that produces the executable. I copied the interop files from the bin folder into the new solution folders
Just include x86 and x64 folders in your solition explorer. Then set Copy to local=true. I will create folders with sqlite.interop.dll
Had a similar issue, resolved it by simly creating the x64 and x86 folder on my startup project as follows:
I am using a separate class library project to communicate with the sqlite db. This is where I copied the sqlite.interop.dll files from
I'm trying to build a VS2015 ASP.NET v5 web app on our build server (basically, outside of Visual Studio). Our existing scripts simply invoke msbuild with the csproj file, but with this project I get:
Project File is empty
What is the "story" for "building" these new webapps outside Visual Studio? I believe they can still target .NET 4.5 (I hope so, as we're not upgrading web servers any time soon) so assumed it were possible.
Well there is no .csproj in a dnx project everything that is needed for dnu to build a project is contained in the project.json. There is a xproj file but you can ignore that. Microsoft has finally decided to see the light and uses xproj just for VS specific "stuff" and IDE agnostic project details are put in the project.json.
So to build a dnx project all you need is the right version of dnx and the project source code. Now AFAIK there are no out of the box solutions but everything is done with command line commands so script something up should be easy. It all depends on how robust of a solution you want to build.
To build a dnx project from the command line (assuming you have the proper dnx installed and set to active) it is just two commands. dnu restore runs a dependency check and dnu (a part of dnx) has a built in nuget client so it will reach out and grab dependencies if needed. dnu build runs that actual compilation.
So cd to the project root (which contains project.json) and run dnu restore then dnu build.
It gets more complex if you need to dynamically support different dnx versions. Keep in mind dnx versions are identified by runtime (coreclr or clr), architecture (x86, x64, etc), and a version number. So if you are only targetting say x64 builds on clr (full .net runtime) that eliminates two variables but what happens if a project requires a newer version of the runtime than what is installed on the build server? As an example say you installed (manually using dnvm) dnx-clr-win-x64.1.0.0-beta4 on the build server but at some point in the future a developer requires dnx-clr-win-x64.1.0.0-beta6-1200 to resolve a bug.
The simplistic solution would be just to install new runtime versions as needed and build all projects against the newest one needed. This isn't as bad as it might first sound. Once dnx gets out of beta changes to the runtime should be infrequent. Remember the runtime is the very low level code and unmanaged dlls. It is the bootstrapping stub that the BCL sits on top of. Hopefully there should not be that many changes to the dnx for a given OS, architecture and runtime.
For a more robust solution you could use scripting to find the runtime version required for a project. It is found in a solution level global.json. The script could then use dnvm list to determine if it has that runtime installed. If it doesn't then use dnvm install or dnvm upgrade to install the required version. Before starting the build it would use the command dnvm use to make the correct runtime active and then proceed with dnu restore and dnu build.
Honestly I expect some pretty robust solutions to come along. Task runners (gulp, grunt, etc) are first class citizens in .NET 5. Most likely your workflow will involve bower for client side dependency resolution, npm, grunt/gulp and some task packages for things like minifying js files. The build server is going to need all that as well so having a build task as a grunt or gulp package seems a pretty good fit.
I have a perfectly working windows forms C# .NET 4 application that uses a SQLite3 database file to store data and display forms.
When I deploy my app on any machine other then the dev machine, I get an exception thrown and it's message is "Could not load assembly System.Data.SQLite.dll or one of its dependencies. The specified module could not be found."
The System.Data.SQLite.dll reference in the project is set to Copy Local = True. Also, I tried manually loading the assembly with Assembly.LoadFile. The dll is placed in the output directory. I also tried setting the platform target to Any CPU as well as x86, no difference. All machines I am working with are 32-bit. What is the issue here? Why is my application trying to load the assembly and can't find it?
Thanks!
I had the same problem after publishing my program to a separate computer. Installing Microsoft Visual C++ 2010 Redistributable Package (x86) on the separate computer fixed the problem.
Note: the separate computer already had Microsoft Visual C++ 2010 Redistributable Package (x64) installed, the x86 version was needed.
'System.Data.SQLite.dll" requires "msvcr100.dll" which is one of it's Dependencies. This will be available only if you installed latest "Microsoft Visual C++ Redistributable" or any other product which internally provides this.
For example, VS2010 will install C++ Redistributable by default. Thats the reason your application doesnot works in some machine but works in others.
You could try pasting the "msvcr100.dll" in your application bin folder and distribute if you dont want to install VC++ 2010 Redist in all the PC's.
Some of the System.Data.Sqlite.dll modules depend on the "Microsoft Visual C++ 2012 Redistributable Package" .
You can find required dependencies on the official download page : http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
The answers already given didn't solve my problem. I tried to deploy to a VMware server. The solution that did help where given here: http://sqlite.1065341.n5.nabble.com/System-Data-SQLite-Deployment-Mystery-td71752.html Two methods are described there.
When i install this sqlite-netFx45-setup-bundle-x86-2012-1.0.88.0.exe, my app is able to find the right dll.
The second method is to add the dll to de app.exe.config in the debug or release dir. If you edit this file directly, there is a change VC will overwrite the file.
My main problem was that i installed the sqlite package manually. I didn't use NuGet, because i'm behind a proxy. If you do use Nuget, the information in the app.exe.config will be provided automatically.
Using NuGet behind a proxy is described here: NuGet Behind Proxy