We are a small team, working on a ASP.net Web Application project, following is the solution structure,
Solution:
Project: Data Access Layer
Project: Model Layer
Project: Business Layer
Project: Web Application Project
For source code repository, we are using Visual Studio Online, since team is small so we are using the Free version.
We are now trying to maintain the proper version for each release. Currently we publish (using publish tool Visual Studio) in a folder, then manually copy and paste files on server Website folder. So right now, the web application's DLL file is having version 1.0.0.0 all the time.
Now we want to use the VSO Build Feature, and each time when we run the build, we want this to happen.
Compiled website
Full code should (all projects) also be copied along with published files
The website DLL's build number should be increased automatically
I am NOT sure if all the above can be done on build or is there any other procedure. Can someone please point us in the right direction?
Thanks.
That can all be fine with the build on VSO. If you are using the XAML build you don't need anything else. Just configured a new build and out It at your solution. You will then get versioned output. To get the build output to have the version number incremented you will need to use powershell and call that during the build.
http://www.codewrecks.com/blog/index.php/2014/01/11/customize-tfs-2013-build-with-powershell-scripts/
Related
I have a ASP .NET Core 3.1 application which is hosted as a windows service using IHostBuilder.UseWindowsService call. I am preparing a setup project using Visual Studio Installer Projects Extensions. The project is created as Web Setup project type so that the installer dialog already presents to the user selection of web page and application pool on IIS.
The problem I'm facing is that the assemblies are successfully installed in given folder on IIS, but the ApplicationService.deps.json is not installed. Without this file the application does not start successfully. As far as I have checked the file is created as part of the build in bin\x64\Release\netcoreapp3.1\ but is apparently not included by the Setup project.
I've played around also with Setup project's property PublishProfilePath by specify the profile that I generated when manually trying to publish from Visual Studio to IIS:
However, this produces even stranger results. The application is deployed to the IIS already when I build the Setup project! Then when check the newly created msi, it's size is really small and in fact does not install anything (completes successfully though).
Any help would be highly appreciated.
I managed to solve the problem, though I'm not sure if that's the optimal solution. In the setup project, you can include as part of the output also individual files. If I add the ApplicationService.deps.json it is marked with a relative path in the setup project itself. This means that once setup project is being build, the ApplicationService project is anyway built first as it's the primary output of setup project. At that point `ApplicationService.deps.json' is present in the Release folder. Then as msi is being created it's included as part of the output.
It works, but I would prefer that the setup project would include that file automatically.
I'm trying to create exe/msi for my solution
it contains the following Projects
ActiveDirectoryEngine: library used to implement AD operations
ADService: windows service - performs the work in the background
CryptographyEngine: library used to encrypt/decrypt data
TerranovaActiveDirectoryHost: Dashboars/win form to manage/check the service's status
SyncToolSetup: the setup project "it only targets TerranovaActiveDirectoryHost"
Here is the contents of the Setup project:
I tried the same steps for different Solution, with ONLY one windows forms application, and it worked fine, but it looks that it doesn't work when I have more than one referenced projects.
The install and Uninstall options are not enabled
Update:
all the previous projects are referenced in the Win forms project, so am I targeting the right one when creating the exe/msi?
The only project with the Install option is the setup project. Other projects in the solution do not have install option just because there is a setup project as part of the solution.
References in a non-setup project (such as a C# build) are not automatically included in a setup project. References used to build code are not necessarily things that need installing on the target system. The setup will try to help with dependencies, but it's unreliable, and only a guide. For example, your Application Folder view contains some files that are part of the .NET Framework, and you definitely don't install them because they are installed as part of the standard .NET framework install.
The setup project must be told what needs to be installed on the target system. There are generally two ways of doing this:
Selecting project output as input to the setup project. This can be rather indeterminate because it's not always obvious what files are included, or what to do if the files need installing to different locations.
Add the files that you know you need one at a time by adding them in the File System view of the directory they need installing into. Typically, executables go into the Application Folder (defaults to Program Files..), data files to User's Application Data, shared files to Common Files folder, some assemblies to the GAC and so on.
I am writing a C# Pre-compiled Azure Function Project in Visual Studio 2017. Before abstracting the POCOs into a separate class library I was able to publish to Azure. (The benefit was separation of the business logic and objects from the Azure Functions allowing me to test each unit.)
When debugging locally I receive no errors. The error is when I click "Publish" on my Azure Functions project and the deploy script starts. The error received in the Output window immediately after "Publish Started":
{VSPath}\Microsoft.Common.CurrentVersion.targets(750,5): error : The OutputPath property is not set for project 'Loans.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Release' Platform='Any CPU'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [{Path}\Loans.csproj]
A Copy of the csproj files Containing the respective OutputPath's and configurations exists on my GitHub.
I have Visual Studio 2017 15.5.3, .NET 4.6.1, extension for Azure Functions and Web Jobs Tools 15.0.31106.0
How can I publish to Azure Functions while abstracting my business logic away?
I updated my extension for Azure Functions and Web Jobs Tools from 15.0.31106.0 to 15.0.40108.0 and I can now publish.
Like comments suggested I tried setting the OutputPath property manually but that didn't fix it. I tried changing the other property values as well to no avail. Reinstalling/Updating the Azure Development Workload probably would have solved it as well as that would have been latest.
I am currently running into an issue where I have an mvc project and an API project in the same solution,Visual Studio 2017.
when I build the solution the structure is as follows
solution
solution/area1
solution/area2
solution/api
I am able to reach the api with no issues when just building on my local machine, but when I go to publish the solution the api project builds the dlls but does not build out the solution/api so I cannot navigate to my api calls.
I have tried setting up multiple start up solutions which did not resolve the issue.
When you build on your local machine, you probably use '(Re)Build solution', which builds all projects in the solution.
However, there is no such thing as 'Publish solution'. You can only publish a Project. When you do that, only the project and all its dependencies are built & published.
if your API is in a seperate project and not referenced from the MVC site, it will not be built nor published together with that MVC application.
There are two viable approaches:
You integrate the API in the MVC site (same domain, same routing mechanism, probably seperate area).
In that case I would suggest keeping it in the same project for simplicity.
You develop the API as a seperate application in its own (sub)domain.
Here you put it in its own project. And you build and publish it on its own, seperate from the MVC application.
msbuild MyProject.csproj /p:DeployOnBuild=true;PublishProfile=<profile-name>;Password=<insert-password>
https://stackoverflow.com/a/14232754/2183503 has the answer.
Note: It has some spurious information (regarding passing vs version) though. For example, I tested the command out out just now and it worked fine without the /p:VisualStudioVersion=11.0 in Visual Studio 2019 Developer Command Prompt.
I have two separate projects/solutions. One is an ASP.NET web app and the other is a console app that runs as a WebJob on Azure. These two separate projects/solutions share some common projects' DLLs.
We work on these shared projects through the web project's solution in Visual Studio and when done, I copy and paste the DLL's into the bin folder of the console app.
When I compile the console app, I notice that the shared DLL's revert back to a previous version. I know this because I see the Date Modified dates of those shared DLL's. The moment I compile the console app, they go back to previous versions.
Why is this happening and how do I prevent it?
You definitely should not drop assemblies into output folder by hand as they will be overwritten from whatever location build takes them from. If you have to do it manually - copy files over original location. To debug - enable verbose logging for build and carefully check where assemblies are copied from.
Automated solution integrated with the build is better approach.
Standard solution for sharing assemblies between project is NuGet. As most basic solution you can just use file share to drop packages. Check out guidance for continuous integration build system you are using as there is probably recommended nuget source (i.e. package feed in VSTS).