Reference search not considering packages\package-name - c#

I'm building a new pipeline in Azure DevOps and I am having an issue with one of the packages not being found (AWSSDK). Looking at the logs I can see that it is not searching in the obvious place which is D:\a\1\s\packages\AWSSDK.2.3.55.2\lib\net452\
See below the places where it is looking for the dll file. The rest of the logs after line 72 are about other C:\ places.
These logs are from an earlier build step which would restore the packages. Line 145 tells us that the package was added in the right place.
I am really not sure how to troubleshoot this, and also I am not sure if I can actually jump on the VM where this is build and investigate further.
Also here is an image with the steps of the agent.

After doing more digging around, I found that in the csproj file the hint path for the reference was not set correctly. After I've changed it to the following, everything worked fine.
<Reference Include="AWSSDK, Version=2.3.55.2, Culture=neutral, PublicKeyToken=9f476d3089b52be3, processorArchitecture=MSIL">
<HintPath>packages\AWSSDK.2.3.55.2\lib\net45\AWSSDK.dll</HintPath>
</Reference>

Related

How can I clean the publish folder so a DLL doesn't keep getting copied to my website?

When building my solution, the most recent (v6.2.1) RabbitMQ.Client.dll ends up here:
C:\inetpub\wwwroot\MyProject\RabbitMQ.Client.dll
I don't want that version. I referenced the latest RabbitMQ.Client.dll DLL in a project, by mistake, then undid that and referenced a previous version (v5.1.2), but the new one keeps showing up in wwwroot when building (we have a post-build event that publishes).
I cleared the NuGet cache, but it's still happening.
I searched for RabbitMQ.Client.dll in our solution folder and found these, all v6.2.1 (the new one, not what I want), in every one of our projects:
bin\Debug\netcoreapp2.2\publish\RabbitMQ.Client.dll
Is there a way to clear that folder? I'm guessing that's why the wrong version keeps ending up in wwwroot when building/publishing. Running Clean, in VS, doesn't do it.
Just add an automated MSBuild target to every your project's csproj file.
<Target Name="DeletePreviousPublish" BeforeTargets="_CheckForUnsupportedTargetFramework">
<RemoveDir Directories="$(PublishUrl.Remove($(PublishDir.LastIndexOf('\'))))"></RemoveDir>
</Target>
If your $(PublishDir) ends with \, you should use $(PublishDir.LastIndexOf('\'))) to make it as a folder so that RemoveDir will work.
If not, just use
<RemoveDir Directories="$(PublishDir)"></RemoveDir>.
And then, when you click Publish button, it will first remove the previous publish folder and generate the new one. It is automatic, so you no longer need to manually delete the folder.
Update 1
It is quite an issue and should be automatic to remove the previous and then use the latest used ones. From a purely vs usage point of view, this is an obvious issue. I have reported the issue on our DC Forum.
You can vote it and add any comments under the link if I did not describe the issue in detail. And hope the Team will fix the issue.
Since the process will take a long time and for now, you have to use my solution to get what you want.

Visual Studio build - Issue with comma in path

I have some external project libraries that I'm pulling into my ASP.NET app. All projects are stored in TFS and locally stored in a relative directory like so: "C:\Users\Admin\OneDrive - Company Name, LLC\Projects\Workspaces\..\..". I've been using this same structure for the past YEAR. However all of the sudden I am having an issue compiling this project where VS is doing something odd with one of the external projects path. I'll see these different errors like so:
'C:\Users\Admin\OneDrive - Company Name', or one of its
dependencies, was not found.
'LLC\Projects\Workspaces\Project1\Project1\bin\Debug\Project1.dll',
or one of its dependencies, was not found.
As you can see, for whatever reason Visual Studio is splitting the path on the comma, which is messing all of this up. I have found this CodeProject post that explains the EXACT issue I am having, however his "solution" is not a workable solution in a TFS environment.
The main issue I am confused about is that these errors didn't start to appear until this past week. I had just pulled our most recent source from TFS, and then it broke. Obviously this points to some sort of difference in the way this lib was referenced, however nothing had changed. It was referenced via:
<Reference Include="Project1">
<HintPath>..\..\Project1\Project1\bin\Debug\Project1.dll</HintPath>
</Reference>
I also tried adding it as a project reference instead, as it SHOULD be:
<ProjectReference Include="..\..\Project1\Project1\Project1.csproj">
<Project>{50063d52-d6f3-46dd-b001-778222ef5864}</Project>
<Name>ArcadiumLeadCommon</Name>
</ProjectReference>
Other things to note. Been using VS 2019 for about a month now, previously using VS 2017. Tried VS 2017, but it fails as well. Build also seems to fail in the same way via cmd prompt with msbuild and devenv.
One solution would be to find a way to rename my one drive folder name to exclude the comma, however even if I find a way to do that, it could break MORE things. Ideally I'd just like to get it to work like it did before. The folder structure is the exact same as before, so there should be a way.
Is there something obvious that I am missing?
UPDATE:
Figured out a quick and dirty "hack" that wont break other shortcuts and pinned document links. Use the 'mklink' cmd to create a junction point between onedrive and some other folder location. For example:
mklink /J "C:\OneDrive\" "C:\Users\Admin\OneDrive - Company Name, LLC\"
Afterwards the project built successfully. Still would prefer it to work like it did, however this is an acceptable workaround for the time being. Hope this helps someone else too.

Building asp.net MVC application in VSTS

I have been using Visual Studio Online for my MVC application for a while now, but I have only been using it mainly as a way to manage my work, cloud storage and version control in case I need rollback something that I made a mistake on.
It has gotten to the point in time where I need to start managing my releases properly rather than just managing it in a folder structure. (I know, I am fairly unprofessional).
So, I am trying to use CI in VSTS but all of my builds are failing. It seems that I am missing all of my NuGet packages. Here is the log from my NuGet restore
https://hastebin.com/ufibohoqir.tex
I have read up a bit on a nuget.config file, which I don't have. I have tried to research into this but I am fairly lost. Do I need this file? I don't use any other packages except for nuget.
Any help would be appreciated. I use VS2015, and I can build using it. I have no idea why it can not find the nuget references.
Thanks!
EDIT
Here is the Log of the build that failed. https://file.io/cRydzZ
It was too big to put the whole thing on Hastebin. Bu, here is a snippet of the log of when it started to break.
https://hastebin.com/ubofozirop.vbs
EDIT 2
After changing my Agent Queue to Hosted, as was suggested, the NuGet packages all seem to be restored successfully. The build is still failing though. Here is my .csproj file: https://hastebin.com/iravicayek.xml
One of the things that I have noticed is that the packages that are not found when building are the ones that look like this in the .csproj file:
<Reference Include="Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
<HintPath>..\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll</HintPath>
<Private>True</Private>
</Reference>
All of the ones that don't have HintPath and Private elements as children seem to load. I tested to see if I removed the children from the Reference elements, but they still failed to build.
For the reason why you can not the nuget.config file used for NuGet restore task, is caused you were use Hosted VS2017 agent.
If you want to build your project with VS2015 on hosted agent, please use Hosted agent (which installs VS2015) instead of Hosted VS2017 agent (which does not install VS2015).
Besides, if the build still fails with missing reference, please check the path for the referenced packages in the .csproj file.
The path for the Antlr3.Runtime package in your project file also seems incorrect. Please change the Reference for the Antlr3.Runtime package as below and then try again:
<Reference Include="Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
<HintPath>..\packages\Antlr3.Runtime.3.5.1\lib\net40-client\Antlr3.Runtime.dll</HintPath>
<Private>True</Private>
</Reference>

C# visual studio how to relocate nuget package folder?

I hired a contractor to do some coding for me. He setup nuget.config in the solution folder with the following repository path:
<configuration>
<solution>
<add key="disableSourceControlIntegration"
value="true" />
</solution>
<config>
<add key="repositoryPath"
value="../lib" />
</config>
</configuration>
And I'm not too happy about his decision: this will place the nuget package folder outside the solution folder. I can easily change the repository path, simply by setting:
value="../<mySolutionFolder>/lib" />
However when I do this a curious thing happens: every single reference that I use in my solution is now broken. And nothing that I change in the .csproj files or other *.config files will allow my projects to find their references.
The only workaround is to re-create each project in my solution by starting from scratch, and add->existing items, etc. and reference->manage nuget packages, and install every reference again.
I have many projects in my solution and performing this for every one is understandably time consuming.
I would like to know if there is an easy way?
It seems like there should be a way for Nuget and VS to play nicely so that I can easily move the repository folder to a different path location.
One way to fix the reference paths is to use the Package Manager Console.
From the Package Manager Console you can run the following command to reinstall the NuGet packages which will fix the hint paths for the references.
Update-Package -reinstall
This will reinstall all NuGet packages in the solution. I am assuming you have the code under source control so you can see what changes are made to the projects if you need to revert them after this reinstall.
There is more documentation on reinstalling NuGet packages on the NuGet documentation site.
Another way to fix this is to do a find and replace in the .csproj files to fix the hint path.
I encountered this problem when I moved the actual folders around in my solution. I usually do a find/replace with VS Code looking for >..\packages\ and replace it with >..\..\packages\. This time I did the following:
Perform Update-Package -Reinstall
this worked for everything with hint paths
does not work when your project uses NuGet packages to build your project because there are custom MSBuild statements that need to be manually fixed, see next step.
Edit the .csproj files manually that do not build, in my example:
<Import Project="..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="..\..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" />
Notice that there are 2 condition statements in the <Import> that use relative pathing to ..\..\packages.
Hopefully these steps will help someone else.
Package.config is used for put file somewhere else from the folder, it help best to not upload package unusually when you add something in your project through Nuget.
Try to copy the package to that folder (new path you set) or simply close the project, open it again and click on Restore after going to Manage project reference.
After trying all solutions posted here I could not escape one primary issue: references to non nuget items, such as System and System.Core remained invalid (yellow triangle listed next to them). Removing them and adding them did not make them valid again. Further (as we all know) Visual Studio is terrible and giving reasons for why a reference is considered invalid.
So while Matt's solution does indeed relocate the nuget package folder, the solution in not left in a working state. Further, updating hint paths did not help because those are specific to the nuget packages. I cannot explain why basic references suchas System also become invalid. Perhaps someone reading this a year from now can leave a message with an explanation.
What I ended up doing is rebuilding my entire project without a nuget.config file (I deleted it). This causes nuget to use all defaults. Downloaded packages get stored in \\<solution_folder>\packages\. After the solution was working again, I added back the nuget.config file but with the following removed:
<config>
<add key="repositoryPath"
value="../lib" />
</config>
...and removing that section causes nuget to rely on default behavior which turns out to be exactly what I wanted (installing packages to \packages, etc).
If anyone else is about to undertake this laborious effort, I found this SO solution helpful for moving folders and files from the old solution to the new one.
I managed to do this to my own solution without realising how (and ended up with a packages folder at the *.sln level and another one at The level below that) - but I'm pretty sure now that this all has to do with migrating from using a packages config file, to the new method of using package references. This can occur if you use a newer version of visual studio (which is possibly what your contractor did) or via a button/commend in NuGet, or via a right-click context menu.
One of the things that happens is the creation of a 'global' packages folder (the one at .sln level) which is meant to save your space since it means you can have multiple solutions using the same package without having huge duplicate package folders repeated in every solution.
I found this out when I was merging The text is two csproj files and needed to Google: import project difference to package reference
See https://learn.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

aspnet_compiler looking for jsharp code provider on a C# mvc2 application

I am compiling an MVC2 application in Visual Studio 2010 on Windows 7 64-bit. I am running the following as a post-build event command:
aspnet_compiler.exe -v / -p \
It results in the following error:-
The CodeDom provider type "Microsoft.VJSharp.VJSharpCodeProvider, VJSharpCodeProvider, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" could not be located
I have no J# in my solution. I've downloaded the J# 2.0 redistributable package Second Edition, but that didn't help.
The funny thing is, I ran this in a BRAND NEW MVC2 solution and got the same error! So it has nothing to do with my application.
What am I missing that's causing this error?
I have read many other posts that say you need to install the redistributable, add a reference in web.config etc. but they didn't help.
Any ideas??
I had this happen today, and found a solution of sorts.
I'm using VS 2010 and an ASP.NET MVC 3 site, using Razor, running in IIS (not IIS Express or Cassini).
In my case this error cropped up in my .cshtml views. For any view I opened, the first #using line was underscored with the error:
C:\PathToMyCode\PathToMyViews\Index.cshtml: ASP.NET runtime error: Could not load file or assembly 'VJSharpCodeProvider, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. An error relating to security occurred. (Exception from HRESULT: 0x8013150A)
There were also bizarre errors throughout the page, such as ambiguous references between two assemblies with the same name (e.g. a supposedly conflict between "System.Web.Helpers" and "System.Web.Helpers").
The cause: I was running the web site under a user account that didn't have sufficient permissions. The account had the IIS_IUSRS role, but apparently there's some other role or access it needs to make this work, or it may need access to a particular folder it couldn't get to.
Unfortunately, I don't know what it is, and I'm not excited about the idea of wasting hours to figure it out after I already spent way too much time trying to figure out how this happened in the first place.
But giving that user the Administrators role resolved the error.
I realize this isn't an ideal solution, but I hope at least it gets some people unstuck. If anyone figures out exactly what permissions are necessary to prevent this error, comment below and perhaps we can narrow it down.
#Adrian - I had this problem today and fixed it nearly straight away, it was trying to compile J# in a C# project, weird error. But the problem was I copied a .java file into my project folder and the issue occured. Once I removed that, it all compiled again fine.
#Kyralessa : I was having the exact same error. Adding the Administrators role to the user under which the website was running "fixed" the problem but as you said it is not an ideal solution.
So I was fiddling around with IIS settings and under the Basic settings of the website I switched to "Application user (pass-through authentication)" and the problem disappeared. The app pool still runs under the same (non-admin) user so there is no security issue.
Try installing one of the packages below:
32-bit: http://www.microsoft.com/download/en/details.aspx?id=18084
64-bit: http://www.microsoft.com/download/en/confirmation.aspx?id=15468
This got me past the error when none of the other solutions would work.
I was having this same error when I set MvcBuildViews property in the csproj to true. After much research and trial/error, I learned that the problem was because our site had .java files in the site's structure. These java files were not a part of the solution, simply loose files. The Aspnetcompiler task runs from the project root, so it finds all kinds of issues like duplicate web.configs and *.java files.
To deal with this, I created the following target in the MVC project file I was trying to debug:
<Target Name="MvcBuildViews" AfterTargets="Build" Condition="'$(MvcBuildViews)'=='true'">
<!-- This task performs compilation of the CSHTML files in the web structure
and will generate compiler errors if there are issues in the views, such as missing
resource strings, broken class locations, etc.
Due to an issue with the AspNetCompiler task identifing .java files as candidates for
compilation, we will temporarily rename all of the java files in the project to .xyz
so they are skipped by aspnet compiler. Then we rename them back.
Extra web.configs also cause an error, so those are temporarily moved. -->
<CreateItem Include="$(ProjectDir)**\*.java">
<Output TaskParameter="Include" ItemName="JavaFolderA"/>
</CreateItem>
<CreateItem Include="$(ProjectDir)obj\**\web.config">
<Output TaskParameter="Include" ItemName="ExtraWebConfigsA"/>
</CreateItem>
<Move SourceFiles="#(JavaFolderA)" DestinationFiles="#(JavaFolderA->'$(ProjectDir)%(RecursiveDir)%(FileName).xyz')"/>
<Move SourceFiles="#(ExtraWebConfigsA)" DestinationFiles="#(ExtraWebConfigsA->'$(ProjectDir)%(RecursiveDir)%(FileName).ccc')"/>
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
<CreateItem Include="$(ProjectDir)**\*.xyz">
<Output TaskParameter="Include" ItemName="JavaFolderB"/>
</CreateItem>
<CreateItem Include="$(ProjectDir)obj\**\web.ccc">
<Output TaskParameter="Include" ItemName="ExtraWebConfigsB"/>
</CreateItem>
<Move SourceFiles="#(JavaFolderB)" DestinationFiles="#(JavaFolderB->'$(ProjectDir)%(RecursiveDir)%(FileName).java')"/>
<Move SourceFiles="#(ExtraWebConfigsB)" DestinationFiles="#(ExtraWebConfigsB->'$(ProjectDir)%(RecursiveDir)%(FileName).config')"/>
</Target>
Hope this saves someone the 3 hours it took me to figure out...
Update:
Because this does add more time to the build, you may choose to add to the condition at the top to only perform this check during Release style builds:
<Target Name="MvcBuildViews" AfterTargets="Build" Condition="'$(MvcBuildViews)'=='true' AND '$(Configuration)' == 'Release'">

Categories

Resources