I have three different build configurations defined for my projects: Debug, RELEASE and PRODUCTION (Difference being in the fact whether we want to encrypt the db and create logs or we wan to do both or just one of these. Basically combinations of thsese three).
Now, in my code (which is a UWP app project) if I try and do something like this:
#if DEBUG
It works fine and the code written in this if block is enabled and compiled if target is set to DEBUG. However when I try and write something like
#if RELEASE or #if PRODUCTION the code written inside these if blocks never get executed no matter if the target is set to RELEASE or PRODUCTION.
So it looks like it's only able to figure out the DEBUG mode.
Go to project properties and on Build tab in line "Conditional compilation symbols" add word "RELEASE" in release configuration and "PRODUCTION" in production configuration
Related
Trying to deploy a multi-project app to azure using pipelines. After trying various combinations (pipeline log is showing about 75/80 runs in the last couple of days), it looks like the problem is with the Dockerfile by Visual Studio 2019 or with the Azure Pipeline somewhere.
Here's what I've narrowed it down to:
Project A-
create a vs asp.net core webapp project, say test1sp,
select the checkbox which says create solution and project in the same folder,
select docker support (I selected Linux) or add it later
no code added, the boilerplate code runs fine as-is
add it to GitHub
create a project/pipeline in azure, source Github, I use the classic editor without YAML
create a docker build/push task and setup, I choose the most basic options, subscriptions, etc.
build works great, I also added a deploy to app service task and it deploys to the app service
Project B - my project is called demo8
Same as project A, except for step #2 - do NOT select create solution and project in the same folder. Follow the rest of the steps and now you should get this error.
Step 7/17 : COPY ["demo8/demo8.csproj", "demo8/"]
...
...
##[error]COPY failed: file not found in build context or excluded by .dockerignore: stat demo8/demo8.csproj: file does not exist
It works fine on localhost/docker. So, I'm guessing maybe vs2019 uses some more tolerant implementation to patch it over. Or, there's a problem with azure's implementation or something else?
I am relatively new to Dockerfile editing and see lots of detailed/complex scenarios, hopefully, someone can shed some light on how to get it working?
Here's a screenshot of the project files/structure:
UPDATE -
Moving the Dockerfile to the solution folder in project B makes it work in azure BUT
then it does NOT work in Visual Studio, no debugging, etc.
make a copy of Dockerfile in project & parent folders ( + keep in sync )
BUT if your solution has multiple projects like mine then
you have to name the Dockerfile different to have unique names in the parent folder
and modify the pipelines to use respective file names
Posting it here in case it helps someone.
The code in the Dockerfile must have the relative path to the folder level that the Dockerfile is in.
Tow ways to solve the problem. One is the change the code in the Dockerfile, for the project B, you can change the COPY code like this:
COPY ["demo8.csproj", "demo8/"]
Another way is to move the Dockerfile to the path that matches your COPY code. But in this way, it may affect other codes in your Dockerfile.
And you'd better plan your projects in different folders and create the Dockerfile for each project in different folders.
I just ran into this problem with a default console app in VS2022. I fixed it by changin the "Build context" parameter in the ADO build pipeline's Docker "build and push" step from the default of ** to **/.. so that the working directory was the solution folder, which matches VS (AFAIK).
Similar to #Josh's answer above -- I explicitly set
buildContext: '$(Build.SourcesDirectory)'
in the Docker task in the Azure Pipelines YML file, and it worked like a charm.
Something for the Azure pipelines template maintainer(s) to look into perhaps?
I would like to run a specific test fixture every time I build my Android application in Android Studio.
I've tried writing a custom task, and causing "preDebugBuild" to depend on my custom task. This doesn't work, and says that it fails to find dependencies.
My task body basically looks like this:
task runTests(type: Test){
}
I had hoped that this task would run all the tests in my project, and that I would then be able to put in some additional configuration to specify a single test, but I can't even get this task to run.
My questions are:
Is there something easy that I am missing to get my "runTests" task to actually work.
Is there some other way to run a specific unit test during the build preDebugBuild step of the Gradle build?
Thanks!
In the Run/Debug Configuration (click on "Edit Configuration" in the selector on the left side of the run button) you can select the "+" button on the bottom and select "Run Another Configuration" and a list of your unit tests should show up.
When using the Visual Studio Test task in Release Management, the release always returns:
No test assemblies found matching the pattern
currently Test Assembly is set to: **\*test*.dll;-:**\obj\**
I have tried multiple defaults like $(System.DefaultWorkingDirectory), etc.
The documentation I've been able to find is either not current with the existing layout of tasks, (such as the Publish Build Artifacts screen no longer containing the Contents box), is for the on premise Visual Studio 2015, or related specifically to the Build.
I've read and attempted the following:
https://msdn.microsoft.com/Library/vs/alm/Release/getting-started/deploy-to-azure
https://msdn.microsoft.com/Library/vs/alm/Release/author-release-definition/understanding-tasks
https://msdn.microsoft.com/en-us/library/gg265783.aspx#Activity_RunTests
http://blogs.msdn.com/b/visualstudioalm/archive/2015/07/31/dev-test-in-azure-and-deploy-to-production-on-premises.aspx
http://blogs.msdn.com/b/visualstudioalm/archive/2015/05/29/testing-in-continuous-integration-and-continuous-deployment-workflows.aspx
UPDATE:
I added a step to the build to Copy and Publish the test.dlls. They are now located. They all fail, due to missing other code, but they are located.
UPDATE II:
My 3_Run_Tests.log file contains the following clues:
Error calling Initialization method for test class ... To run tests that interact with the desktop, you must set up the test agent to run as an interactive process.
Test Run deployment issue: The assembly or module ... directly or indirectly referenced by the test container ... was not found.
Because of the above, I am going to accept #eddie-msft's answer.
You need to make sure that the complied file of the project which you'd like to test is also been copied and published to the same path with Test Assembly. The test will fail if only Test Assembly is copied.
I assume you are working on a C# project, in the step to copy test assembly, you can set the copy content as this:
**\YourTestProjectName\bin\$(BuildConfiguration)
I have been having a similar issue. Multiple projects in build and the test file would not be found.
No test assemblies found matching the pattern *test*.dll;-:\obj**
Fix: added additional build step "build solution" and "Copy Files to". This build was pointed to VS solution file with automated test. "Copy Files to" was left at default
How do I have SSDT run my publish script when I build my solution file?
If you:
1) Right click on your solution
2) Click Configration Properties
3) Click Configuration
I can see the database project and where it is checked to deploy on build, it does not let me specify what publish script to use.
As far as I know this isn't possible out of the box.
Why? They are two very different things.
Building (if you were to think of it as code) compiles and checks, producing artefacts. For .NET code those artefacts are DLL's/.exe etc. For .sqlproj it's the .dacpac etc that turn up in /sql/[Build Configuration Name].
Publishing is akin to Deploying if you were talking .NET code. Building won't include Publishing as an action.
Ironically, a Publish action also Builds the solution, so my suggestion would instead be to consider one of the following:
Publish the project (right click Publish, or double click your chosen .publish.xml file) whenever you want to build.
Use the Post-Build command line in the project Properties to call sqlpackage.exe to deploy your newly compiled .dacpac with your specified .publish.xml profile - but note that this will also impact your use of the Publish action from within Visual Studio as a Publish builds and then publishes (so you'd end up publishing twice).
Depending on your comfort levels/if you are a command-line fan, then use the command line (bash file? Powershell?) to call msbuild followed by sqlpackage.exe. Whenever you want to build, run your command in cmd.exe.
Similar to #3, add a menu item to the Tools menu that would do exactly the same thing (msbuild followed by sqlpackage deployment) but from within Visual Studio itself.
Look at a Continuous Integration model (TFS/TeamCity/Bamboo/Jenkins and about 3000-others), which could build and deploy for you automatically with every change - either on another server, or running locally (I put this in without knowing your scenario, so may be very much unsuitable to solve your problem).
I have a build definition set up that successfully builds on each check-in and deploys to the cloud (Azure). However, I'd like to know how to modify it if I wanted it to build, but not actually deploy to Azure. Just build after the check-in, make sure nothing breaks, and that's it. I've tried searching around and modifying MSBuild arguments, but to no avail. This should be easy. What am I missing?
These are the MSBuild arguments I have plugged in. The last two (DeployOnBuild and CreatePackageOnPublish) don't seem to matter at all...not sure /t:Publish is making any difference either
/t:Publish
/p:TargetProfile=Cloud
/p:DeployOnBuild=false
/p:CreatePackageOnPublish=false
Thanks!
The key is to use the correct build process template:
Right click the build definition -> Edit Build definition
Process tab
Up at the top there is a section for the Build Process Template
Show Details
Select "DefaultTemplate" from the dropdown
The options available in the process tab will be different than the AzureContinuousDeployment template I was using. I didn't need any MSBuild arguments (though you might depending on how you named your service configs).
I had never noticed the template before. Most people probably just assumed I was already using the default one!