Referencing Assemblies when executing U-SQL Application scripts against local-project - visual-studio

I have a U-SQL DB Project (USQLdb) that defines a U-SQL database and it's constituent tables, procedues, etc. This project also references two assemblies for use in one of the stored procedures. The DLL files are held within a folder called assemblies within the U-SQL Data Root folder and are referenced within the database using the following script:
CREATE ASSEMBLY IF NOT EXISTS [Microsoft.Analytics.Samples.Formats]
FROM "/assemblies/Microsoft.Analytics.Samples.Formats.0.0.0.0/Microsoft.Analytics.Samples.Formats.dll";
This works when deploying to Local-machine or to Azure.
For testing purposes, I have added a U-SQL Application Project (USQLScripts) that references USQLdb, with U-SQL scripts that execute a stored procedure each with the aim of setting up Unit Testing.
When trying to run these scripts against Local-project: USQLdb however, database deployment fails. From the logs it is because the USQLdb deployment script cannot find the referenced assemblies in the Local-project data root folder:
*** Error : (204,6) 'Assembly file 'C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot\assemblies/Microsoft.Analytics.Samples.Formats.0.0.0.0/Microsoft.Analytics.Samples.Formats.dll' could not be read.'
I have specified the USQLScripts Test Data Source as the local U-SQL Data Root folder which copies all files found to the Local-project working directory here:
C:\<Solution Folder>\USQLScripts\bin\Debug\USQLScripts_altdata_5qktnwfj.gln\data'
though per the error message above, the USQLdb Assembly Reference is trying to find them here:
C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot
As the DataRoot folder is completely cleaned and recreated on each Local-project execution, how can I either get the assemblies into the DataRoot folder on execution or reference them approriately without changing the address in the U-SQL script included earlier, which works as required when deployed to Azure?
Turns out, that if I remove the U-SQL Database reference in USQLScripts, the files that are in the Test Data Source folder are now copied to the C:\<Solution Folder>\USQLScripts\bin\Debug\DataRoot folder, but the scripts cannot execute as the database they are trying to execute against hasn't been referenced. I get the impression that I am either missing something or have hit a bug/unintended behaviour...

Turns out I was missing something.
What I thought was an error in referencing the assemblies was actually an error in building the USQLdb project, that resulted in the assemblies not being available and a red herring of an error being thrown.
The culprit was the Target Framework Version of the assemblies being higher than both the USQLdb and USQLScripts projects. It appears this can only be changed by editing the .usqldbproj files manually in a text editor (specifically the <TargetFrameworkVersion> value), as there is no option within the Visual Studio UI to edit this project property that I can find.
Once I upped the Target Framework Version in the U-SQL projects to match those of the assemblies, everything now builds, deploys and executes as expected.

Related

Visual Studio Remove Unused Nuget Dependencies

i am struggeling for a while now with removing unused dependencies from bin output folders.
I am for example writing a small .NET Wpf program which gets its data from a Web server. Therefore i installed the System.Net.Http NugetPackage to make my Get / Post requests. The Package Information is stored in the .csproj file.
When i compile the project a lot of Dependencies are added to the output folder
Sytem.Security.Cryptography.Algorithms.dll
Sytem.Security.Cryptography.Encoding.dll
Sytem.Security.Cryptography.Primitives.dll
Sytem.Security.Cryptography.X509Certificates.dll
...
None of these dependencies are explicitly used in my program, means when i delete them from the output folder and start the application everything works as expected.
I do understand that this Dlls has to be in the package, but how can i ignore them. Is there a way to ignore dependencies within a nuget package?
One way to accomplish this is to set copy local to false on the Dll reference.
I haven't worked on WPF projects but I believe this would still apply.
To do this expand the References node in the project, select the Dll and then in the Properties window set the "Copy Local" property to False.
This should prevent the Dll from going into the bin and also from being included when published.
One word of warning though, the application may work now but doing this creates a potential trap for future you or other developers. If code changes down the road require one of these Dlls your application won't be so happy and then you'd have to remember to put the Copy Local back to True.

xUnit console runner cannot find json files with MS Test runner

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.

TFS Build 2013 - Cannot resolve primary reference

I'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.

Add files as read-only to project?

I have the following problem: I need to create a VS project (database project) and I want to make it deployable. To do that I need to add a single SQL function, which belongs to a pool of global functions, to the project. If I now deploy the project, I have all the files that I need.
Problem: I don't want anyone to change the global function inside of my project, so I would like to set it to readonly (not the file itself on the filesystem, it's checked in tfs anyway), so that the file can be deployed, but no one can change it inside the project (at least not by accident).
Is it possible to add a file as read-only to a VS2010 project?

Why is my Visual Studio Cloud Project recursively nesting its package in my Web role build output?

I have a pretty simple Could Project (named Uploader.Cloud) with one Web Role (UploaderWebRole) and I'm trying to build them using visual studio. I've modified the project files of both of these projects to change their output path to a different place than the default spot. What I'm finding is that I'm getting a MSB3021 build error when I build Uploader.Cloud:
Unable to copy file "D:\Enlistments\FB1\Dev\Izer\Build\Release\Cloud\Uploader.Cloud.csx\roles\LogUploaderWebRole\approot\bin\Uploader.Cloud.csx\roles\LogUploaderWebRole\approot\bin\_PublishedWebsites\UploaderWebRole\bin\Microsoft.WindowsAzure.Diagnostics.dll"
to "D:\Enlistments\FB1\Dev\Izer\Logging\Uploader.Cloud\obj\Release\LogUploaderWebRole\bin\Uploader.Cloud.csx\roles\LogUploaderWebRole\approot\bin\Uploader.Cloud.csx\roles\LogUploaderWebRole\approot\bin\_PublishedWebsites\UploaderWebRole\bin\Microsoft.WindowsAzure.Diagnostics.dll".
The specified path, file name, or both are too long.
The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Upon further inspection, I find it odd that the bin folder of my web role (LogUploaderWebRole\approot\bin) has a cloud package in it (Uploader.Cloud.csx). I don't think that should be the case and am curious if this is a bug in my configuration or if there's a bug in how Visual Studio's Azure tools are building my project.
Any help would be appreciated!
I found the issue. I modified the OutputPaths of the Uploader.Cloud and LogUploaderWebRole projects to build to a different spot. On top of that, Uploader.Cloud was using a web role named LogUploaderWebRole, but the project was named UploaderWebRole. Replacing all instances of LogUploaderWebRole with UploaderWebRole in both projects fixed the issue. For some reason, having the different names caused the build process to nest Uploader.Cloud.csx in multiple levels of the build directory hierarchy.

Resources