Cannot publish web service - Error : Could not open Source file: The given path's format is not supported - web-services

We are trying to publish a web service from our Dev box onto the UAT box.
There are no errors when building the web-service, but when trying to publish (using UNC path: \\TEST-SERVER\c$\inetpub\wwwroot\PerformanceReviewWebService) we get the below error message and the process fails:
3>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(1475,5):
Error : Could not open Source file: The given path's format is not supported.
what can we do to track down this error and resolve it?
On the target box we have checked the security of the folder:
..\c$\inetpub\wwwroot\PerformanceReviewWebService
and we definitely have access to write into that directory.
We have no build errors.

Here are a few things you can try that may help debug or resolve the issue:
Try launching Visual Studio as an Administrator and retry publishing.
Try publishing to a local location. Does this succeed?
If yes there is likely a problem with either accessing the UNC path or a file/security permission issue
If local publishing does not succeed, make sure you haven't mistakenly moved any of you bin, contents or webconfig files to a different location.
Check for files in Visual Studio that are light grey, or have an exclamation mark next to them (They may be missing from the project).
Attempt to possibly reload the project to a prior state where publishing was successful. Continue making updates gradually until your project is up to date.
Create a new empty project and attempt to publish to the same location. If this works you have something corrupted or wrong in you existing project. You can try excluding files or folders from the build to narrow down which ones may be causing the problem.

In my case a referenced web-project shared content with the web-project I want to publish. After removing it from the content of the referenced project it was working again.

Related

How to access SSAS deployment log?

By mistake, I added a new calculated member with the same name as an existing calculated member. It added the new calculation without warning.
When I process and deploy I get an error that it failed deployment but no errors or warnings are displayed. I closed VS, restarted the SSAS service, restarted the physical server, but I got the same error. I tried browsing the LOG folder (C:\Program Files\Microsoft SQL Server\MSAS13.MSSQLSERVER\OLAP\Log), but still didn't find anything related to deployments.
After troubleshooting (ie. looking at the DSV, checking connections, and finally deleting all calculations until finding the issue), I finally realized it was a duplicated calculated member.
Was there an easier way to find the issue?
I had a similar issue and found the error in the FlightRecorder in the Log folder:
C:\Program Files\Microsoft SQL Server\MSAS13.MSSQLSERVER\OLAP\Log\FlightRecorderBack.trc
Mine was failing due to having domain users that were no longer valid as members in one of the roles.

Deleting Team Project in Azure DevOps ends in strange folders in Sourcecode Explorer of VS

Following Azure DevOps documentation, I have deleted a number of projects. The project is removed from the online view but strange folders now appear in VS 2017 source control explorer. These folders contain source code from the deleted projects.
I tried to delete and resync my workspace but the unwanted folders synced again. Can anyone who has seen this behavior advise how i can get rid of them?
br Nico
Edit:
It seems like this is not a new issue. I am able to reproduce this with TFVC projects only. Take a look at this post about how to remove "deleted" team projects. Hopefully that gets you moving in the right direction.
If all else fails... use Git :)
Original:
It seems to me like VS is holding onto some information about the remote and which projects it expects to be there.
You may simply need to refresh the connection in VS.
If the refresh still shows the deleted projects, try removing the server connection completely, and adding it fresh.

Azure DevOps project build returning with log4net error

I'm trying to build a visual studio 2015 dot-net application which has log4net reference in the code.
When I build in Azure DevOps using Nuget restore, Nuget Tool installer, Visual studio build, Publish Build artifacts I am getting an error:
Error CS0246: The type or namespace name 'log4net' could not be found (are you missing a using directive or an assembly reference?) Process 'msbuild.exe' exited with code '1'.
Please someone suggest whether I have to add another agent or make some reference to the package/nuget in Azure DevOps. need details since I'm new to Azure DevOps.
The error message suggests that either the using is missing or the assembly could not be found, meaning that probably the nuget restoration has failed.
If you can't figure out the issue by looking at the log, the first step should be to set system.debug to true, then you might get more info about what the issue might be.
My first instinct when I don't know what's going on would alsways be to look into the s folder of an agent but I don't have experience with hosted agents and as far as I know you cannot access the working folder of a hosted agent.
So as a workaround (only if everything else fails) I would suggest to zip the s folder ("$(Build.Sources)") or special parts of it into the a folder ("$(Build.Artefacts)") and publish that zip as an artefact. Then you can download it and look at it in great detail, e.g. look at the packages folder or open the solution and see why it doesn't compile.
Problem was partly solved as there was .gitignore and .gitattribute files in my source directory which i guess had entries to ignore the third party .dlls like log4net and several folders which were not getting checked-in when i did vsts push. But there arose some other errors in vsts build now which i am trying to figure out. I will create a new thread for that.
Thanks.
For some reason I lost ability to see it in
Tools -> Manage Nuget Packages for Solution
However from the docs
I used
Install-Package log4net
in Package Manager Console
That solved the issue.
Previously I had noticed the yellow triangle against log4net In Manage Packages For Solution, and may have tried removing it via Nuget.
However it was still showing as a reference

Visual Studio 2017 2 users on one desktop

I have the following problem: I have a Laptop with two different user accounts (UserA & UserB / they belong to the same person but have different priveleges).
UserA: can build the solution and run tests locally (Everything is working as expected)
UserB: Has the rights to publish to the specific network drive, however he cannot build the project. The reason is that the Windows user itself has not the correct proxy settings configured, and thats why the nuget packages cannot be downloaded.
I have no possibility to change the proxy settings for UserB right now (It depends on internal processes, which might take a while)
However I would have expected, that when I build the solution with UserA, UserB would not need to build it again and just can publish it. This, does not work, as soon as I want to publish, VS tries to rebuild the solution and this does not work because some dependencies are missing and cannot be loaded.
Is there any solution for this problem? I tried to make a research, however I was not really sure for the correct keywords to search for.
Edit: I have now the domain added to my UserB, but I still have some other problems. However I found out that this article is heavily related to my issue: Unable to launch Visual Studio 2015 as a different user.
When I start Visual Studio via Command Line with the mentioned arguments, more works, however I am now not able any longer to connect to my database using Integrated Security = true in the connection string. But at least I can build now. Deploying also works but I just get a 500 Server error when I try to connect to the resource.
Edit2: I needed to add the domain to my user when opening Visual Studio with the command mentioned in the link above. This fixed my problem with connecting to the database.
Actually I do not need an answer anymore for my initial question but I will not delete it because maybe someone has an answer for a person who will have the same question later on.

How do I setup TFS build definition when my localPC, source, build agent, and deployment are all on seperate servers

I'm trying to set up a build definition in TFS 2010. The options for this seem very limited, for instance I have 5 solution files in my source control and I don't seem to be able to specifiy which one to use. I've selected a workspace from my deployment server (which does a TF get every 10 minutes so I know it's a valid workspace), but when the build runs it gives me an error complaining about the mapping - and it seems to have made it's own mapping up from somewhere.
Mapping I set: $/InteractV4/Dev/IV4ProductionSR/
Error: There is no working folder mapping for $/InteractV4/Dev/IV4Support/iv4ProductionSR.sln.
There are 2 issues with this error. 1: it's not the workspace I was trying to use. 2: It's wrong and there is a working folder mapping for this source, both on my local PC and on the deployment pc, but NOT on the build server. Do I need to set up a load of folders and mappings on the build agent server? Or on the main TFS (source) server?
Thanks.
TFS-Builds operate on private Workspaces that get generated during the build process, so using a custom-Workspace is without tweaking impossible.It's possible to keep TFS from regenerating a new Workspace with each Buid, by going to Build Definition edit "Process":"2.Basic":"Clean Workspace" and changing default value All into either Outputs or None.The mappings are set for each Build Defition where various pairs exist:
Source Control Folder | Build Agent Folder
$/foo/bar | $(SourceDir)\somewhere
The $(SourceDir) is substituted during Build and it gets its value from the Build Agent Settings. If you go to the TFS Admin Console & select "Build Configuration", you 'll be presented with a list of Build Agents running on the Server (there might be additional Agents in other Servers). Clicking on "Properties" of an Agent, pops up a Window like that: This entry "Working directory" is the one that resolves & substitutes $(SourceDir) during build.For example, an entry $(SystemDrive)\Builds\$(BuildAgentId) could resolve into something like C:\Builds\88.So, for a TFS Build running on this Agent, you should expect all Sources that stand in source control under $/foo/bar to be found under C:\Builds\88\somewhere
EDITAccording to your comments you have now a mapping like this:
$\InteractV4\Dev\IV4ProductionSR | $(SourceDir)
Your build fails, as "There is no working folder mapping for $/InteractV4/Dev/IV4Support/iv4ProductionSR.sln".
Is this source control directory $/InteractV4/Dev/IV4Support mapped in your Build Definition?