I am playing around with Microsoft's Q# library, and I've gone through the install, however the build is failing and I am having a tough time figuring out the problem. My first suspicion is Microsoft.Quantum.Canon
EXEC : error QS1001: Assembly E:\Projects\Quantum\Microsoft.Quantum.Canon\bin\Debug\Microsoft.Quantum.Canon.dll not found
I also have noticed Microsoft.Quantum.Canon.nuspec is missing. I've tried to do a Nuget.exe restore on the solutions but that did not work.
Has anyone worked through this?
It's been reported on GitHub already, although it appears to be intentional. See the comments in the .gitignore file:
# These files are generated by bootstrap from a .v.template (version template).
# Any changes must be done to the corresponding the .v.template file directly
Microsoft.Quantum.Canon/Microsoft.Quantum.Canon.nuspec
I can't find any info on this .v.template file, probably it's part of internal Microsoft build tooling. You can copy the template file and fill in the missing parameters if you wish, but the file not existing doesn't make the build fail , does it?
I'm getting the following error when attempting to install a nuget package into a standard .NET framework 4.7 project:
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.
I'm using Visual Studio 2017 15.3.3 Enterprise (latest and greatest).
Given that this is my package, I have full control over the source code. The interesting part is that I have used this package in the past with no changes in the name, but for this go round, I rebuilt it to add a feature and am now getting this error.
Even more interesting is that I have packages from the same library, with the same namespace conventions, with longer names, that work just fine and have installed into this same project with no problems at all.
I have already tried shrinking the package name, shrinking the class names within the package itself, cleaning out the build directory, cleaning out the package home from the nuget server (it's a local server with the latest nuget.server installed which otherwise works just fine), and even clearing out the bin directory of the project in question, clearing out ALL the bin directories of ALL the ancestors to the "offending" package, clearing out the package cache, rebooting the computer and rebuilding the entire nuget package chain from scratch, all to no avail. I was told by one of the MS MVP's that "they fixed that". Apparently not.
Any help would be appreciated here, I'm at my wit's end and have run out of ideas to try.
Thanks.
OK, big Thank You #danmosemsft who suggested digging around with the SysInternals process monitor. After fiddling with it for a bit, I finally figured out how to narrow the result set to just file activity. What I noticed, and the nuget engineers should TAKE NOTE of this: The problem was NOT a too-long project name, rather, nuget was attempting to update a package that was no longer there. Why it went away is a mystery yet to be solved. I normally stay out of the packages directory and do not fuss with the packages.config file. I think that this might have to do with my impatience waiting for VS to start, load all the goodies and then allow me to perform a "Manage NuGet packages" - update all. I remember seeing an update to either NUnit or FluentAssertions that wanted to perform some additional file activity aside from just installing the next version, a script I believe. Can't speak to it with assurance, I wasn't paying that much attention as third party updates usually "just work". I didn't see the "finished" line from NuGet so I think that was the root of my problem. Rather than wait until VS has settled down, I pushed it a bit (hey, the buttons responded so there shouldn't be any problems...).
As a result, the packages directory was absolutely chock full of old stuff that did NOT belong there. So, I manually cleaned up all the cruft, manually cleaned up the packages.config file, restarted VS, waited for it to settle down, performed my NuGet updates and viola! no problem - HAVING NOT CHANGED ANY OF THE ANCESTRAL PACKAGE NAMES BY EVEN A SINGLE CHARACTER.
So, what do I conclude from this? It is my belief, and the guys that actually build nuget and nuget.server should take a closer look at the errors being thrown, such that I think that the error is not so much a path too long error, rather it's a "hey, I didn't find the file I expected so the file name is full of junk (and probably too long now) so I'll throw an error that says it's too long and quit". It's seemingly a failure to handle a missing package/package directory that is causing this particular problem
I solved my problem by ensuring that all the package directories were clean of all junk and rebuilding from a clean source. My problem is now solved.
Thanks to all of you that responded.
Update: While the above contributed to the solution, it was NOT the answer. Here is the sequence of events that led to this problem and it's ultimate resolution.
The solution was created in the C:\User\Sam\Documents\Visual Studio 2017\Projects directory with the specified name of AWE.Lib.ADO.MsSqlSvr.ServerEntityHandler. This worked just fine, no errors. However due to a change in naming scheme from on high, the root directory for this project was changed from "C:\User\Sam\Documents\Visual Studio 2017\Projects" to "C:\User\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x". No problem, I thought - given that a co-worker who also happens to be a MS MVP had told me that all naming length restrictions had been removed in VS 2017. So...I moved the project from it's current home to the directory specified. Compiles just fine, brings in UPDATED BUT ALREADY INSTALLED nuget packages just fine, etc.
Or so I thought. When I needed to add a NEW (one that had not been a part of the solution before) nuget package to the mix, I received the above error. Turns out that the new name of the receiving solution is a few characters longer than VS will accept - the naming length restrictions are STILL IN PLACE.
How did I finally solve the problem: After struggling with this, I threw my hands up and decided to start all over again - a true File | New. So, I started with a new solution named as follows:
"C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEntity"
THIS GENERATES AN ERROR - name too long. I wondered at Nuget's error in that it specifies that the name should be less than 248 characters in length or 260 maximum.
What I am allowed to use iaw the new solution dialog is this: "C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEnt", for a total of 106 characters in length. If the directory is shortened, I can add to the length of the name. If I shorten the length of the actual solution name, again, VS'll accept it. So long as the total length of directory plus solution name is less than or equal to 106 characters, there isn't a problem.
The nasty bit comes from creating the solution in one location and having it work in all respects just fine, moving said solution to a different directory, still having it function in all respects (I did NOT need to add any new nuget packages yet), then trying to add a new nuget package to the mix after the move. THAT is what triggered the above nuget error.
So...the ultimate "fix", use a shorter name as it seems that 106 characters is the limit despite what the error messages are saying (and what the MS MVP was told/told me).
There is another reason for this error message by the compiler.
While building , make sure the source code is placed at a folder location which is less than 260 characters long.
For example, a path like C:\Users\User\source\Services\Exp\Sample-web-application-indot-net-displaying-RestAPI\Sample-web-application-indot-net-displaying-RestAPI\SportsStore is around 150 characters long but there are sub folders in the solution which in turn have source code files and so on.
Sometimes the overall length of the path of some files breaches the 260 character length.
I think the future versions of Visual Studio would have a bigger length allowance. Until then, we can make sure that our file names are not too long.
I was running into the same issue after I moved a project to another folder. In my case I closed VS renamed the .vs folder in root to 1.vs (effectively removing it) and re-opend my project.
In my case, I was first trying to install a package using Manage Nuget Packages for Solutions and was getting this error. Then I tried installing same package using Package Manager Console and it worked fine. I again uninstalled that package and tried installing using Manage Nuget Packages for Solutions and this time it worked fine as well.
Well in my experience all i had to do is move the entire project to my c: drive, delete unnecessary folders to ensure the path would be shorter. Done deal.
This error comes to me when I tried to copy the project folder to OneDrive and the problem is that OneDrive is not uploading long name files.
I've fixed this issue by just copying the project folder then paste it in the new laptop using USB.
I wish this could help
Move the folder of the project to a folder within a few levels from the root dir. For example the Desktop and voila.
Try to close Solution from File->Close Solution and opening it again.
For my case uninstalling, installing, or even updating NuGet packages, nothing was working but reopening(sometimes you can also close and open Visual Studio again) the Solution did the magic.
I downloaded the orchard galley server from codeplex repository in this link:
https://galleryserver.codeplex.com
when I want to run ClickToBuild.bat file according of the Readme.txt file for build and run all of the tests in both projects, show this error:
any one can help me?!
thanks a lot
First of all, the project has been discontinued. So you probably will not have support from the author. second, its from 2011.
Looking at your errors, it might seem you are missing assets being referenced. If you look closely to the project tree and read the Error you will see how there are Nuget packages being used. those might need updating for your project to build.
If it is an old nuget version, depending on your VS version might have problems but it salvageable. Just need to make sure all your packages are updated before building.
If you look at UpdateNuGet.bat you will be able to see how it tries to do something in the folder where the compiler tries to find the asset.
Good luck
I am upgrading an old N2CMS website to the newest version released in the trunk (2.2.5 or something like that), following these instructions https://github.com/n2cms/n2cms/blob/master/docs/releases/upgrade_2.2.1.txt but i am getting an error when tring to compile the project:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Has anyone done this before and know if there's anything else i should be doing appart from just copying files?
Thanks
Complete text of this error contains the name of DLL you are missing. Read it carefully and you will find out what DLL you need to add. It could be something like Lucene.dll which was introduced recently (it depends how old your project is).
I am evaluating PostSharp for a new project but cannot seem to get past the following error when I first build the project after changes:
Cannot copy file "C:\SourcePath\Output\Debug\MyApp.vshost.exe to
obj\Debug\Before-PostSharp\MyApp.vshost.exe: the file is locked by
process(es):MYAPP.VSHOST (8064)
The error only occurs in the first build attempt. If I immediately re-build, the error does not occur. I can only guess this is because the project isn't actually being rebuilt the second time.
I've read a few posts in the SharpCrafters forum that indicate this problem existed prior to v2.1 but was reportedly fixed. I am using v2.1.6.14 from NuGet (in VS 2010) and getting this error for every project I reference PostSharp. It is certainly not reasonable to require 2 builds every time, so I'm looking for a possible solution. I'm really pleased with what I've seen thus far but will have to go another direction if that can't be resolved.
UPDATE
Per Gael's request, I generated the diagnostic build log and sent it to him and it looks like he was able to resolve the problem in the latest release (2.1.6.14).
I believe part (or all) of the issue may be due to the fact that the build output for all of my projects is set to a common location (i.e. not the /bin/debug folder under each project). This is because we are using a MEF DirectoryCatalog which will discover Imports and Exports contained in the assemblies located in the output path. The PostSharp.targets file has the vshost.exe file excluded from the copy operation but only when it shares the name of the output assembly. In my case, the vshost.exe file has a different name and was, therefore, not being excluded.
The issue has been re-fixed in PostSharp 2.1.6.15.