I've built a .NET Core 2.1 MVC project which containing appsettings.js as config instead of web.config.
I had to add reference to a dll as a requirement of the project, that referenced dll need config values from web.config file. But the problem is .NET Core 2.1 MVC project doesn't contain a web.config file.
Please help me to find a solution. Thank you.
You just need to create web.config at the root of your project.
When the application is published, the compiler always creates a web.config, if it already exists in your project, it will get your changes and add on publish web.config
Related
I have a .NET Standard 2.0 class library project with installed Nuget package System.Data.SqlClient version 4.4.0 and a Windows Form .NET Framework 4.7 project that has a reference to that class library.
Installing the Nuget Package and building the solution is successful. but in runtime every time that the code reaches a method that has any thing from SqlClient assembly inside it (for example an instance from SqlConnection) it gets this error:
Could not load file or assembly 'System.Data.SqlClient,
Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Considering this question, I assume the problem was also there in the last major version of the Nuget package.
Edit
I downloaded the Nuget package and unzipped it and from \ref\netstandard2.0 folder copied the System.DataSqlClient.dll manually in \bin\Debug folder of my Windows Form Project and now it works. The exact situation also happened with Microsoft.Win32.Registry package. So I was almost convinced that it's my fault and I'm doing something the wrong way, but when I tested it with System.Drawing.Primitive Package it worked perfectly without any need to copy a dll. Now I'm really confused.
I guess you may have figured it out already but hope it would help someone - wasted some time too on this.
So, in order to make everything work you would need to reference System.Data.SqlClient in Windows Form project that is referencing your .NET Standard Library
From that point everything should be working like a charm
As you already mentioned System.Data.SqlClient.dll was not in output directory.
Sounds like .NET Standard Library haven't grabbed with itself dependent library binary. There is nothing like "Copy Local" option in .NET Standard references so I don't see any way to check or set this behavior too
I had same problem.
Solution for me was adding dependecy from nuget for latest System.Data.SqlClient at my .NET Standard Library project.
I had the same problem. The .NETStandard assembly was added as a reference to my WPF project. I needed to make changes in the .csproj of the WPF project.
The solution mentioned in https://github.com/dotnet/sdk/issues/901 fixes it.
Steps:
Edit your core .csproj file in notepad.
Add the below two lines in each that you find in it.
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Clean and rebuild your solution.
I had a similar problem, bindingRedirect helped in my case:
<bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="4.4.0.0"/>
I'm using TeamCity to build and publish my .NET core application to NuGet.
I've been using the project.json file for storing the version, but with the latest version of .NET core the project.json file has become obsolete, since everything has moved to the project's .csproj file. So I'm trying to find a new home for the version information.
Here are some possibilities that I can think of.
Continue using project.json, but only for storing the version information (doesn't feel like a permanent solution)
Storing the version in a separate file like version.txt
Somehow storing it in GitHub using tags or something alike. This feels like the ideal solution.
I like option 3. the most, e.g. for storing release points (1.0, 2.0, etc.) and then using some date time appended afterwards. But I'm unsure if that's possible or even recommended.
What is the recommended way of storing the version information, given that you have your project in GitHub and that you're using the latest .NET core?
Is there a problem with having it in the .csproj file?
As for recommendations - there are various ways you do this which you choose is up to you.
With .NET Core the assembly information can be specified in the project file (.csproj). How you have it defined in the project file is up to you.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
<AssemblyVersion>1.4</AssemblyVersion>
</PropertyGroup>
</Project>
You could have it hard coded. Or run some other MSBuild task to generate it.
AssemblyFileVersion and AssemblyInformationalVersion should work in the same way.
When you build the project an AssemblyInfo.cs file is generated in the obj/Debug/netcoreapp1.0/ directory.
I've an asp.net core project with appsettings.json file being copied to the output directory on each build with following "copyToOutput" option in project.json file. When I build it and go to the build folder I can see it. But when I build a Service Fabric application that uses this asp.net core project as service, in package folder, appsettings.json file is missing. Are there any issues with processing content files for asp.net core?
Actually, the problem was related to the fact that there is being called dotnet publish step when creating ASF package. Hence "copyToOutput" was supposed to be done via "publishOptions".
I'm trying to create a nuget package which will both add a DLL and configure it inside of the proper configuration file. The package can be used in either a console/form application or a web application, so I want to update the appropriate configuration file, either app.config or web.config.
My files section in the .nuspec file contains the following inside of the section.
<file src="config.transform" target="content\app.config.transform"/>
<file src="config.transform" target="content\web.config.transform"/>
The .nupkg file does contain both of the transforms inside of the content folder.
When I add my package to a project in VS2010 through Manage NuGet Packages, the only file which is ever modified is the app.config file. Web.config is never touched. In fact, in a web application with an existing web config, NuGet will create an app.config file which contains the modifications.
Is there a way of doing what I'm trying to do (and if so, how)?
According to a related bug report, it should already work how you want it to. Are you running the latest version of NuGet?
My ASP.NET MVC 2 application uses Entity Framework 4.0 for the data model. Following the instructions on http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx I put the .edmx in its own assembly so my solution has two projects:
MyApp.Core (ASP.NET MVC 2 Web Application Project, references MyApp.DataLayer)
Models/
Controllers/
Views/
Web.config
MyApp.DataLayer (Class Library Project)
Entities.edmx
App.Config (<-- generated by edmx when I update model from DB)
When I regenerate Entities.edmx, it creates the App.Config file under MyApp.DataLayer with connection strings to the database. The problem is that when I deploy the solution, the Web.config is the only config also deployed, so I have to manually add these connection strings to it otherwise I get an exception at runtime because they cannot be found.
I'd like to not the same connection string defined in both Web.config and App.Config. How should I organize my projects/config files such that the connection string to the db are found in only one place? Is this possible?
You can either embed the autogenerated app.config in your Model project and reference the connection string when you create your DataContext using GetEmbeddedResource...or (the more normal approach) copy the connection strings manually from the auto-generated app.config to your web.config.
If you want to be really ingenuitive, create a simple T4 template that copies the app.config connection strings in your web.config when you generate the EDMX model.