I have a build definition, which uploads artifacts (loads of css, js, aspx, dll files etc.) and is working as expected.
I now try to configure a release definition with the AzureRM Web App Deployment step to deploy this to a web app.
The web app already exists and I can deploy to it easily directly from Visual Studio.
In the step I have filled in the following fields:
AzureRM Subscription (appears as expected in the dropdown)
Web App Name (appears as expected in the dropdown)
Package - I want to include all files, so I've set it to $(System.DefaultWorkingDirectory)/MyBuildDefinition/**/.
SetParameter File - left blank
When I try to run the deployment the process finds the first file matching the flag and then fails with the following messages:
2016-08-31T16:01:37.7827094Z msdeploy.exe is located at 'C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe'
2016-08-31T16:01:37.7867084Z filePath = Find-Files -SearchPattern C:\a\r1\a/MyBuildDefinition/**/.
2016-08-31T16:01:38.3277086Z filePath = C:\a\r1\a\MyBuildDefinition\Web\App\app\build\css\brand-style.css
2016-08-31T16:01:38.5537092Z ##[error]Cannot process argument transformation on parameter 'files'. Cannot convert value to type System.String.
2016-08-31T16:01:38.5907083Z ##[section]Finishing: Deploy web app
I am using an OOTB hosted build server.
I also tried running this with Package field set to a zip file, which I created for testing, but this didn't work either.
How can I take advantage of this step in my scenario?
Can this consume non-zip files?, if it has to be zip then how do I generate it from my artifacts?
Ok, got it.
It can't be just a normal zip file. It has to be a zip file generated using MSBuild.
Related
I've got a class that I want to test with xUnit. This class loads a .json file containing configuration for this class in the constructor. By default, this json file is loaded from the current directory. This works fine in my application, as it can resolve the current working directory. This json file has the Build Action = Content and Copy to output directory = Copy Always to ensure the file is always along side the DLL files.
However, when calling the tests from within the VisualStudio test runner, the DLL's are run from the tempory files location: C:\Users\<username>\AppData\Local\Temp\3c081508-0a25-45f0-8813-48d4fcabccaa\3c081508-0a25-45f0-8813-48d4fcabccaa\assembly\dl3\4175808c\f164e239_d1a1d201\SomeLibrary.dll where each DDL required is in a separate file, and the .json file is nowhere to be seen. This means the code that loads the .json file from the current ddl location is failing. The functionality happens when running the tests from both within VisualStudio, or from within the xUnit.console application.
To overcome this, I've added a configuration option, and if that configuration option exists (which I add to my test project only), then use that path instead of trying to load the path from the current ddl. However this is now failing in bamboo, as that path is invalid when executed on the build server.
Is there anyway to get the temporary path programatically to where the .json file is... Or someway to disable using these temporary files and just use the actual bin dir in the project build dir for the VisualStudio test runner?
Currently using VisualStudio 2017 and xUnit 2.2.0.
Cheers,
Justin
There is this option for xunit tests called Shadow-copy assemblies being tested. It ensures that the assemblies being tested are copied elsewhere to allow the original assemblies to be modified while running and without affecting the tests.
Turning off this feature should help in your case.
Shadow-copy assemblies being tested can be turned off in Visual Studio at
Resharper -> Options -> Tools -> Unit Testing -> Shadow-copy assemblies being tested.
When submitting an app and test assembly to Xamarin Test Cloud using test-cloud.exe (version Xamarin.UITest.1.3.9.1500-dev) we also need to submit an App.config file (as our test assembly relies on configurable appSettings).
Initially I had hoped that everything within the bin directory (either Debug / Release depending on --assembly-dir provided) would be uploaded to Test Cloud.
This does not appear to be the case, my App.config file (XamarinMobileTests.dll.config) present in the bin directory is not uploaded.
So, to address this issue, I have attempted 2 potential solutions, none of which I have had any success with, these are as follows:
Using the --data parameter with the submit command (--data XamarinMobileTests\bin\Release\XamarinMobileTests.dll.config). This always seems to return an error: "Data files must be located in the assembly directory or a sub folder."
I have attempted to put this file in various locations, with no luck.
Specify appSetting values within the --test-params parameter. This executes the submit command without error and instantiates a test run in test cloud. However, the Xamarin.UiTest Sdk does not seem to have any support for accessing the --test-params specified. My only option seems to be using the Xamarin Web Api, figuring out the test run (also not available via the Sdk) and then fetching the test-params from the test run meta-data.
The documentation on their site is extremely limited for these parameters.
Has anyone experienced similar issues in the past or found a potential solution?
Ideally, the config file is uploaded by default. However, if this is not an option, then solution 1 would be my preferred choice.
Turns out the issue was with a trailing "\" on the --assembly-dir that was causing the config file specified in --data to not be uploaded.
Changing:
".\XamarinMobileTests\bin\Release\"
to:
".\XamarinMobileTests\bin\Release"
Resolved the issue and the config file was successfully uploaded.
It looks as if the test-cloud.exe does some flakey comparisons on file paths.
I have a content file (xml, build action = content, copy always) in a class library (dll).
Many times when the host application (unit test dll, or web app) get recompile due to changes, this content file is not deployed.
it only get to deploy if i explicitly perform a "rebuild" at the host application.
is there a setting a way to ensure the file always get redeploy? already set it to "copy always", but doesn't work as expected.
There are two ways to solve this:
1) If you change non-source code files visual studio doesn`t automatically rebuild - they aren't considered when the compiler check occurs.
You may force a complete rebuild by deleting your output directory.
2) In the file properties in Visual Studio, set:
Build action: None
Copy to output directory: Copy always
Sometimes this helps
Edit: Also consider marking the file as content
Normally when I am writing a desktop application (in Visual Studio) and need to include a certain file in the build directory I just use the 'Copy Always' option in the file properties. However, I am finding that if I use this option in a Windows Store App, the file will appear in the build directory, but is nowhere to be found when the application is deployed. I have tried marking the Build Action for the file as 'content' and a few others, but no luck.
How do I get my files to show up in the deployment directory?
We are trying to adapt a build automation strategy for our ASP.NET web site (not a web project) in vs 2010 ultimate & tfs 2010.
Build definition makes the build and publishes the web site into folders like
<drop_folder>\<defn_name>\<defn_name>_<year><month><day>.<build no>\Release_PublishedWebsites
Now we try to delete particular files and folders from that folder. For instance the "images" or "files" folders, that we need to exclude before packaging. I know that if it were a web project, there exists a straightforward solution. We also tried to modify the build process template (xaml) file. There is a "DeleteDirectory" component but we couldn't figure out what to write to the Directory variable.
Thank you.
If you follow the XAML way, you would just have to feed the Directory argument of DeleteDirectory with the physical UNC path to the folder you 're trying to get rid of.Something along the lines of String.Format("{0}\\{1}\\{2}\\Release_PublishedWebsites", BuildDetail.DropLocation, BuildDetail.BuildNumber, Date.Now.Year)
should get you near to your target. Since the drop location of the build might be on a different machine, also ensure that the account conducting the build (by default = NetworkService) has the rights to delete folders on the target.