I am looking for a step by step guidance to deploy a c++ winforms application into Azure DevOps.
I have a legacy application and its already into TFS server but now the team has planned to put it into Azure DevOps and automate the builds and release process.
I did some researches and tried something and it partly worked out. But, I cannot understand whether to go by GIT or TFVC (Team Foundation Version Control)?
As, the application is already into TFS, I believe it will be easier to create the repository and pipeline using TFVC. But, what if I want to do using GIT? What are the factors I should consider when using GIT?
NOTE: I do not have TFS server access but I do have Azure DevOps access.
What I have tried:
Created a demo project. Below are the details about the demo project:
<code>Project and Solution Name -> SampleApp
Solution file location -> "C:\SampleProj\SampleApp\SampleApp.sln"
Other project files location -> "C:\SampleProj\SampleApp\SampleApp"</code>
Tried to deploy the above sample project into Azure, using GIT. The steps I followed are given below:
<code>
1. Installed GIT.
2. Logged into dev.azure.com with my credentials.
3. Created a new project and copied the 1st link as provided in "Repos" section.
4. Created a ".gitignore" file from Visual Studio Team Explorer -> Settings -> Repository Settings.
5. Went to the project folder (C:\SampleProj\SampleApp\SampleApp\) and right-clicked and selected "GIT Bash Here". The GIT command prompt opened up and typed the following commands:
a. git init
b. git remote add origin [URL copied at step 3]
c. git add .
d. git commit
e. git push -u origin master
</code>
After these steps, the repos in Azure were holding all the files except the solution file (.sln) and when I created pipeline for builds, the builds started to failed as it was not getting the .sln file.
I cannot understand the below mentioned points:
<code>
1. For all projects, I cannot find Repository Settings in Team Explorer. Why so?
2. If I have a legacy application already in TFS, can't I make it done using TFVC instead of using GIT?
3. What are the correct steps being followed in the industry?
</code>
I did some researches and tried something and it partly worked out.
But, I cannot understand whether to go by GIT or TFVC (Team Foundation
Version Control)?
Git is distributed system while TFVC is centralized system. More into about their difference you can refer to this document.
But, what if I want to do using GIT?
About moving from TFVC to Git you can consider using git-tfs tool. More details check this guide.
Tried to deploy the above sample project into Azure, using GIT. The
steps I followed are given below:
If you have a newly created project, you can easily add it into git source control in Visual Studio and then push it to Azure Devops Service project. Please check Share your code with Visual Studio 2017 and Azure Repos Git.
For all projects, I cannot find Repository Settings in Team Explorer.
Why so?
You need to add the solution into source control in VS first, then you can find repository Settings in Team Explorer=>Settings=>Repository Settings.
Hope all above helps and it could be better to separate the different questions in your post into different threads.
Related
So I was able to publish my wpf application using click once without any problem for a couple of months. But yesterday when I tried I got an odd looking message.
When choosing Yes option the publish stops and fills error list with those errors:
I tried searching online but without any success.
I resolved this issue by unchecking the passive mode check box when prompted for the ftp credentials
This issue started happening to me after I upgraded to Visual Studio 2019 16.7.3. I also updated my application from .NET Framework 4.7.2 to 4.8. (Although I doubt that's the issue, I did not revert to 4.7.2 to test it.)
My solution was to publish to a local folder and then upload those files with a separate FTP application (e.g., FileZilla). Upgrading my existing ClickOnce app worked fine.
Details: In your application's Properties page, select the Publish tab. Change the Publishing Folder Location field from "ftp://whatever" to "C:\publish-MyApp." Click the Publish Now button. VS will create the files pretty quickly. Next, use your FTP application to upload the contents of the C:\publish-MyApp folder to the existing installation folder on your server. This overwrites the existing setup.exe and MyApp.application files and adds a new folder (e.g., MyApp_1.2.3.4) in the Application Files folder.
(One side benefit of this method is that it's faster to publish because FileZilla is a lot faster at uploading than Visual Studio.)
I'm currently working on a live project. The frontend part of the system is in ReactJS. We are using create-react-app as the starter kit.
We are facing some issues in deploying the application on live server. Earlier we followed the strategy of pushing the code on server and then creating the build on it. But we noticed that so long the build was generating, our site became unavailable. Which does not seem right. Hence we decide to create build folder in developer's local machine and push the build to the server. But now we are receiving a lot of change requests and feature requests, hence I'm planning to move to a robust git branching model. I believe this will create problem with the way we are currently handling our deployment strategy(which is to move the build to production).
It will be really helpful if some one can show us the right direction in handling deployment of ReactJS apps.
You can use Jenkins which can be configured to trigger the build as soon as a code in a branch is checked-in in GIT. I have not worked on Jenkins but surely, I have seen people using Jenkins for such things.
Jenkins will trigger the build in its own environment (or you can create a temp folder for the time being the build is getting generated if Jenkins operates on the server directly) which will generate the output bundle. So your code will not be removed from the server for that while and you can patch your new files to the actual folder (which can also be automated using Jenkins).
I would like to be able to publish from visual studio. I am able to do this
I have different configurations for Debug,QA,Release. I am using config transforms and they work fine.
ISSUE: when I publish the I want the Debug, QA,Release to be published to their respective folder example E:\Application\Debug and so on. I am able to do this by changing the Publishing folder location and Installation folder location manually. How can this be such: f I change the configuration these locations are selected automatically. So when I need to publish a particular version -> and all I need to do is
change the config
press the publish now button.
Thanks!
The only possibility I know of would be to use a Build Server and build if the Source code changes (probably seperate branches) and have build definitions for each case.
This would mean that you would have to have a kind of source control (Git, Mercurial, TFS) for the Project and the resources to run that kind of service or use a Service on the internet.
Build Server for local installation:
TeamCity
Team Foundation Server
Build Server via Internet:
VisualStudio.com
(Those are the onse that come to my mind because I have used them before. There are much more available)
With a 2012 SSDT database project and a Integration Services project within it using project deployment model, after a build, a .ispac file is not created for me. Is there a setting or option that is necessary to allow this to be created?
The project builds successfully, and successfully creates the .dacpac file too. Building from the solution or individual project, the .dacpac file is created, and I see both projects are built successfully when built from the solution. I can also successfully create a .SSISDeploymentManifest file too. Of course, the run the all the packages without error as well.
Also, the Non-Default Properties Report shows only MaxConcurrentExecutables and EnableConfigurations for project level properties have non default values.
I feel like there is something small I'm missing. Any help is appreciated.
If a package is converted to use the package deployment model, a .ispac is not created when the project is built. It is only created when the project is using the project deployment model. The answer was in the question the entire time...
Our team develops distributed winform apps. We use ClickOnce for deployment and are very pleased with it.
However, we've found the pain point with ClickOnce is in creating the deployments. We have the standard dev/test/production environments and need to be able to create deployments for each of these that install and update separate from one another. Also, we want control over what assemblies get deployed. Just because an assembly was compiled doesn't mean we want it deployed.
The obvious first choice for creating deployments is Visual Studio. However, VS really doesn't address the issues stated. The next in line is the SDK tool, Mage. Mage works OK but creating deployments is rather tedious and we don't want every developer having our code signing certificate and password.
What we ended up doing was rolling our own deployment app that uses the command line version of Mage to create the ClickOnce manifest files.
I'm satisfied with our current solution but is seems like there would be an industry-wide, accepted approach to this problem. Is there?
I would look at using msbuild. It has built in tasks for handling clickonce deployments. I included some references which will help you get started, if you want to go down this path. It is what I use and I have found it to fit my needs. With a good build process using msbuild, you should be able to accomplish squashing the pains you have felt.
Here is detailed post on how ClickOnce manifest generation works with MsBuild.
I've used nAnt to run the overall build strategy, but pass parameters into MSBuild to compile and create the deployment package.
Basically, nAnt calls into MSBuild for each environment you need to deploy to, and generates a separate deployment output for each. You end up with a folder and all ClickOnce files you need for every environment, which you can just copy out to the server.
This is how we handled multiple production environments as well -- we had separate instances of our application for the US, Canada, and Europe, so each build would end up creating nine deployments, three each for dev, qa, and prod.