We Keep Coding

error MSB1003: Specify a project or solution file. building a pipeline with azure and can't find csproj file

Hi I've got a solution that has multiple projects held within it where I'm hoping to automate the build and deployment of the webapplication within the project.
on my HD the dir looks like C:\Users\mleip\source\repos\edocs.utils.bluebeam-api\edocs.utils.bluebeam-api.Caller\edocs.utils.CDEComms , however, when I run the below yaml
i get
MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet restore
- powershell: |
Write-Host "Your parameter is now: $env:Param"
Write-Host "When outputting standard variable build id: $(Build.BuildId)"
Write-Host "When outputting standard variable build id via env: $env:BuildNumber"
Write-Host "The repo name is: $(Build.Repository.Name)"
Write-Host "The build definition name is: $(Build.DefinitionName)"
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/edocs.utils.bluebeam-api.Caller/edocs.utils.CDEComms/edocs.utils.CDEComms.csproj'
So far I have tried several combinations of dir for where azure should locate the build file, however, each time it fails. The solution has several projects within it. CDEComms is the only project within that folder so I'm left quite confused as to what's going on.
I'm quite new to building pipelines and any help as to why this is failing would be greatly appreciated.

In order to narrow down the issue, try to simply specify **/*.csproj in the YAML file to check the build result. And set variable system.debug to True, to check whether the path is correct in C:\hostedtoolcache\windows\dotnet\dotnet.exe build {path}. Also, clone the repo to your local machine to run build it locally, to check the result.

From the description you have provided, you will first have to push your code/solution i.e. the content of your C:\ drive to your repository.

How to open Visual Studio Code with admin privileges to make effect of the installed extensions

I have Ubuntu 16.04 and I have to download the C# extension for Visual Studio Code, once I installed it, It doesn't make effect. Then, vscode give me and advice that I should open vscode with admin privileges to make effect of the extensions installed, so I wrote on my terminal:
sudo code .
but it doesn't work, the terminal throws me:
It is recommended to start vscode as a normal user. To run as root, you must specify an alternate user data directory with the --user-data-dir argument.
but I don't know how to specify an alternate user data directory. I was searching how to do that in visual studio code docs but there is not a reference for this issue. If you know how to open with admin privileges in linux please help me.

To run with superuser:
$ sudo code --user-data-dir=~/root
By the way you will be able to run without setting params in the upcoming patch 1.5.0.

You can achieve this in either of following ways :
Run vscode as superuser:
$ sudo code --user-data-dir=~/root
This will open vscode without your previous settings (fresh) with superuser privileges and you can install your extensions.
OR
Follow these steps :
sudo chown -R <user> <path_to_your_vscode_installation_directory>
Hit follwing in terminal
to check the current user on your machine :
whoami
for e.g. john
You can find path of vscode directory using following command :
whereis code
e.g. in my case path is : /usr/share/code
Now run :
sudo chown -R john /usr/share/code
This will run vscode with admin privilege
Now install your extensions
After reset owner back to root
sudo chown -R root /usr/share/code

My simple solution is:
sudo code --verbose --user-data-dir --no-sandbox
(not as root but as sodoer user)

You can press Shift+Cmd+P in visual studio code and type:
shell command
and press "install" in the PATH.
Then in your terminal go to the folder that you want to open and type "code ." It'll open the project in visual studio code as root.

To able to run vs code as superuser:
open code file with a text editor
sudo nano /usr/bin/code
then comment on the following line of codes :
if [ "$(id -u)" = "0" ]; then
for i in "$#"
do
case "$i" in
--user-data-dir | --user-data-dir=* | --file-write )
CAN_LAUNCH_AS_ROOT=1
;;
esac
done
if [ -z $CAN_LAUNCH_AS_ROOT ]; then
echo "You are trying to start Visual Studio Code as a super user which isn't recommended. If this was intended, please specify an alternate user data directory using the \`--user-data-dir\` argument." 1>&2
exit 1
fi
fi
to
#if [ "$(id -u)" = "0" ]; then
# for i in "$#"
# do
# case "$i" in
# --user-data-dir | --user-data-dir=* | --file-write )
# CAN_LAUNCH_AS_ROOT=1
# ;;
# esac
# done
# if [ -z $CAN_LAUNCH_AS_ROOT ]; then
# echo "You are trying to start Visual Studio Code as a super user which isn't recommended. If this was intended, please specify an alternate user data directory using the \`--user-data-dir\` argument." 1>&2
# exit 1
# fi
#fi

here's a step-by-step solution on how to resolve the error "You are trying to start Visual Studio Code as a super user which isn't recommended" when upgrading VS Code in the terminal:
Open a terminal window and navigate to the directory where the VS Code executable is located.
Run the command:code --no-sandbox --user-data-dir=/my/custom/data/dir .
This will start VS Code without the sandbox and use the specified directory for user data.

In my case, in OpenSuse tumbleweed, I performed a couple of extra steps:
I needed to invoke sudo telling it to preserve the environment as vscode (X11 really) needs to know the value of the DISPLAY environment variable.
I wanted to reuse my existing data dir and installed extensions.
sudo -E code --user-data-dir=$HOME/.config/Code --extensions-dir=$HOME/.vscode/extensions
After I am done with my editing / debugging session, I needed to reset the permissions of the data dir and extensions, like so:
sudo chown -R your-user:your-group $HOME/.config/Code $HOME/.vscode/extensions
Where your-user and your-group correspond to your uid/gid which you can obtain from the id command.

Use TFS 2013 to version Windows Store App Builds

We are using TFS 2013 to manage our source code for a Windows Store app. Unfortunately, it looks like we have to change the version number manually. This is tedious and easy to forget. If we use the wrong build twice, we have to take extra steps to deploy. Is there a way to set version numbers when the Build server builds?

You need to execute a PowerShell pre-build on the build server to update the build number. There is an example script as part of the TFS Community Build Tools.
https://curah.microsoft.com/8047/run-scripts-in-your-team-foundation-build-process
Look for ApplyVersionToAssemblies.ps1. You will have to customise to update any manafest files you need...

I found the solution. This will modify the version number in the appmanifest. I'm not sure of the source, if anyone would post the source, I will add this to this comment.
This is a powershell script that I added to the project source control and set it to run pre-build. This worked like a charm for each build for me. This is exactly what I wanted it to do.
# get the build number, we assume the format is Myproject.Main.CI_1.0.0.18290
# where the version is set using the TFSVersion custom build activity (see other posts)
$buildnum = $env:TF_BUILD_BUILDNUMBER.Split('_')[1]
# get the manifest file paths
$files = Get-ChildItem -Path $env:TF_BUILD_BUILDDIRECTORY -Filter "Package.appxmanifest" -Recurse
foreach ($filepath in $files)
{
Write-Host "Updating the Store App Package '$filepath' to version ' $buildnum '"
# update the identity value
$XMLfile=NEW-OBJECT XML
$XMLfile.Load($filepath.Fullname)
$XMLFile.Package.Identity.Version=$buildnum
# set the file as read write
Set-ItemProperty $filepath.Fullname -name IsReadOnly -value $false
$XMLFile.save($filepath.Fullname)
}

How can I prevent bad project references?

We are using C# projects with TFS as source control and for the CI builds.
I keep finding that other developers are referencing assemblies from /Bin directories incorrectly when they should be using our /Libs folder (where we keep 3rd party assemblies)
What can I do as part of the solution build or CI build (we do also use powershell) to check and fail the build if anyone does this?

Add a custom activity to your build process template. The activity's pseudo code should look like:
Execute before the compilation phase.
Loop all new changesets containing file extensions ending with *proj.
For all *proj files, search their contents for HintPath elements containing \Bin.
If results > 0, exit build with error, listing the policy failing projects.
To complete the solution also consider enforcing a custom check-in policy for the VS clients.

Since you are using PowerShell you might as well use it for this problem; the principle is straightforward: parse all csproj files and check if the HintPath doe not contain your Bin directory. In PowerShell that is something like (I've only just begun learning PS so there might be shorter ways):
# define path to bindir (or part of it) and main source dir
$binDir = path\to\Bin
$sourceDir = path\to\sourcefiles
# fix dots and slashes (or anything that cannot be used in regex
$binDirReg = $binDir -replace '\\', '\\' -replace '\.', '\.'
# parse
$res = Get-ChildItem -Recurse -Include *.csproj -Path $sourceDir |
Select-String "HintPath>.*$binDirReg.*<"
if( $res )
{
"ERROR somebody used Bin dir instead of Lib"
}

Storing settings for a nuget package. Is there a better way?

I have a console application that is available via nuget or on it's own. It gets installed into the tools directory for the NuGet package. The application requires 3 pieces of 'configuration' information.
a database connection string
a folder path
one more configuration option (string)
Currently, I store these configuration values in a text file right next to the exe in a file called settings.js, serialized as json.
When the application first runs, if the file is not present, it creates one with default values.
I keep the settings.js file in this location so the file will get checked into source control.
My question is about maintaining the settings file across versions.
If you Update-Package via nuget, everything works great, except the new version doesn't have any settings i had configured, because there is a new folder created for the new version.
I have written a powershell script to run in init.ps1 to pull the settings from the last version of the package, and seems to work. However this feels kinda dirty and I am wondering if there is a better way to solve this problem when using nuget to deliver my application.
param($installPath, $toolsPath, $package)
Set-Alias hump (Join-Path $toolsPath hump.exe)
$sorted_list = new-object system.collections.SortedList
$parent_path = Join-Path $installPath ".."
foreach($f in Get-ChildItem $parent_path -Filter Humpback* | Foreach {$_.FullName}){
$sorted_list.Add($f,$f)
}
if($sorted_list.Count -gt 1){
$old_path = $sorted_list.Values[$sorted_list.Count - 2]
$new_path = Join-Path $installPath "tools"
$current_settings = Join-Path $new_path "settings.js"
$has_current_settings = Test-Path $current_settings
if($has_current_settings -eq $false){
$old_settings = Join-Path $old_path "tools\settings.js"
Copy-Item $old_settings $new_path
}
}
Also, init.ps1 doesn't appear to run when installing a package using the command line tool (nuget.exe). Is this expected behavior?

Can you access System.Environment.GetFolderPath? I'd just create a folder under ApplicationData special folder, and store the settings there.