I have a .Net Core web application that has two .Net Core class project dependencies in the same solution.
The scaffold structure of the project solution is as follows.
MyProject.sln
MyProject.Data
MyProject.Entity
MyProject.WebUI
I want to publish this solution in my web hosting but the publish option only appears on the WebUI does not appear on the solution.
How can I solve this ?
If the UI project has a dependency (i.e. a reference) to the other two projects, then when you build the UI project (which will happen at publish time, if you don't do it separately beforehand), the other two projects will be compiled into DLL files and the resulting DLLs will be added to the build of the UI project automatically. This is how all .NET programs work.
So yes it's logical that you can only publish the UI project - the other two, being simple class libraries, would be no use on their own anyway, so it makes no sense to be able to publish them separately. You can only publish something which can actually be executed.
Related
[![this is my webApi project solution structure.this have multiple projects added][1]][1]
how can i publish these kind of projects in visual studio 2019
[1]: https://i.stack.imgur.com/Z42EP.png
I'm assuming by publish you do not mean you just want the DLL's.
Those are class library projects, they cannot be published by themselves.
If you want to publish a project you need to build either a web api, console application, wpf, web forms, etc. You can then add the class library projects as project references to the project you wish to publish. When you publish one of those projects, the dlls for the class library projects automatically get built along with them.
In the example in the screenshot you provided, you would publish "ThriftPlanningWebApi". That would automatically publish all the dlls for the class libraries along with it.
If you do want the raw DLL's simply build the project in release mode, navigate to the file location of the project. In the bin folder there should be a folder called "release". That folder will contain all your dlls.
Let me know if you need anything else.
Happy coding :)
I was developing an ASP.Net Core Web Api together with dlls specyfic to the domain. I have also developed a dll which turned out to be the one that can be shared across organization as NuGet dll. I created that dll in the same solution where i have my AspNet Core app. In consequence each time I run a build, version of this Nuget is bumbed up even if no changes were made to that dll.
I have 2 questions:
Should I move this Nuget dll to separate repository? Is this a best practice?
Can i somehow configure a task in AzureDevops pipeline in a way that version should be bumped only when there is a change made to that dll?
Should I move this Nuget dll to separate repository? Is this a best practice?
It depends on your actual application. If the project of this NuGet dll in the solution is independent and not related to other projects. The best practice is to move this Nuget dll to separate repository.
This helps to manage the shared nuget dll.
Can i somehow configure a task in AzureDevops pipeline in a way that version should be bumped only when there is a change made to that
dll?
AFAIK, there is no such task to achieve this. But we could try to modify current pipeline to only build AspNet Core app project instead of the solution, and create a new pipeline only build the nuget dll project and give the path filter:
In this case, each time run a build, version of this Nuget is bumbed up only changes were made to that nuget dll project.
So what I'm trying to do is build a .NET Core app with MSBuild, and have it create the web deploy folder but without automatically putting it in a zip file. I can do this for .NET Framework apps by using /p:WebPublishMethod=Package and /p:PackageAsSingleFile=false, it creates the same folder structure but without adding it to a zip file. However with a .NET Core app, it seems to ignore this flag and always zips up the final package.
The reason I do not want it zipped up is I need to add a number of "custom" files to the build before I can deploy it. I can't add the files during the build itself because we have a number of different clients, and they all share the same "base" software, and then the client specific files need to be added afterwords. So I want to build the "base" software, then be able to copy the output folder, add the client specific files, and then zip up that build to be deployed to IIS. This saves a tremendous amount of time because the alternative is doing a new build for each client, even though 95% of the software is the same.
So is there a different way to accomplish this with .NET Core apps?
I've been testing with MSBuild via command line. The solution has a mix of .NET Framework and .NET Core asp.net websites. This is what i'm running:
msbuild.exe "Solution.sln" /nologo /nr:false /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=false /p:SkipInvalidConfigurations=true /p:PreBuildEvent="" /p:PostBuildEvent="" /p:BasePackageLocation="C:\Temp\BuildOutput" /p:platform="any cpu" /p:configuration="release"
This works for the .NET Framework websites, but the .NET Core websites continue to be zipped up
And just a note that the BasePackageLocation is a custom property that sets the PackageLocation to "$(BasePackageLocation)\$(MSBuildProjectName)\" so that each website is put in its own sub-directory
So is there a different way to accomplish this with .NET Core apps?
Sorry but the answer could be negative. This is one issue about publishing .net core projects, it has been reported to Product Team, there might be a long way to go before the fix.
For web deploy package mode in .net core, you'll get WebApplication.deploy.cmd in the same folder where the .zip exists, many commands in the xx.cmd are associated with the xx.zip, so it's not recommended to manually do something to unzip it.
I suggest we can track the issue there(DC) and I will update the answer if there's any update or fix :)
I created a simple Web API project in Visual Studio 2015 using the .NET Core Framework. When I publish this project using the default settings, it creates the following:
In total there are 155 DLLs, 77 in the PublishOutput root and 78 in the refs folder.
Why put all the DLLs in the publish folder? Couldn't it just
reference the DLLs where they were installed from a single shared
location ?
Dotnet core tend to be very minimal as opposed to the previous versions of .net framework.
In dotnet core, the main purpose was making the core framework as small as possible and if you need more stuff, bring it in through NuGet packages.
So, many dependencies that used to be available in the framework are now moved to the NuGet packages and as you know there is a chain of dependencies in NuGet packages, so we will end up with so many libraries in our publish output, which is fine.
Another point being, most of the time, we're using project templates with too many dependencies that might not be needed whatsoever. So we can either start with a very minimal template and add needed stuff in it, or remove useless stuff from a more chuncky template.
I had a similar issue. When my local computer was upgraded from Net Core 2.0 to 2.1, my Core We Application which references a NetStandard application started publishing all DLL's in all referenced projects. I migrated my Core 2.0 application to 2.1 to match the highest version of SDK installed on my local and I could see my issue is now resolved. Publishing from the migrated(upgraded) application produced only the required DLL's. Hope this helps.
I have a ASP.NET Core 1.0 MVC app in solution X and I have some common projects (.net 4.5.2 class libs) in solution Y.
I want to reference the projects in solution Y from my app, when I do so via add reference -> Browse .. I get:
.NET Core projects only support referencing .NET framework assemblies in
this release. To reference other assemblies,
they need to be included in a NuGet package and reference that package.
I then created a nuget package of those projects, added the folder that contains the nuget packages as a repo source and loaded the projects. This adds the projects successfully to my project.json, but 'nothing' else actually happens, I still can't use the code in my app.
Now ASP.NET Core is past its beta status, what is the official way of dealing with this?
Many people have struggled with this issue and there is a long running thread on GitHub about it. Even the people using the latest RC3 build are reporting the same problem that you are having.
The only way I've been able to reference class library projects in an ASP.NET Core web application is to create both the web application and the class library projects in Visual Studio 2015 Update 2. And they all have to target .NET Framework 4.6.1.
I had to copy the code from my old class library projects to the new ones. But in the end I think I saved myself time by not having to mess with all the workarounds that don't seem to work for a lot of people.