This question was originally asked here: http://social.msdn.microsoft.com/Forums/en-US/pex/thread/60972f1f-735a-474e-be84-40cda8006ffa?prof=required.
I've recently installed Moles for VS2010. I have assembly that has same classes (same name) but under different namespace. Moles is resolving this by generating for example MClassName and MClassName01 for those classes. This works locally fine. But when someone else gets latest version, moles are regenerated and what has been MClassName becomes MClassName01 and what has been MClassName01 becomes MClassName, due to which build fails until all unit tests are fixed again. Which is unacceptable to be done on each time when someone gets latest version. Please suggest solution.
The answer at the time was that it was a known bug that would be fixed in a release in December 2010. I'm still seeing this issue in 0.94.51023.0. Is this a regression or was the bug never fixed?
Thanks
Related
It's been a while since I've gotten into nuget hell but I'm back to this again...
I'm not exactly sure what caused this issue other than I did a visual studio 2019 update before I left on Friday. Now today, I've been fighting an issue where my library won't compile due to "Must Use PackageReference".
I've found a few articles out there on this but nothing that seems to specifically address this problem.
This issue could also be due to accidentally adding some .netcore librairies (entity framework .core) to the .netframework library. I had a hard time removing those libraries using nuget.
I also tried to reload the nuget library by:
nuget-package -reinstall Microsoft.Windows.SDK.Contracts
That reloads the package ok, but when I recompile the library the error "Must use PackageReference" comes back again.
In the output window I have this when compiling:
...\path...\packages\Microsoft.Windows.SDK.Contracts.10.0.19041.1\build\Microsoft.Windows.SDK.Contracts.targets(4,5): error : Must use PackageReference
I'm not even seeing this referenced in any of my source files so I'm not sure I even need it. However, I can't uninstall it as it seems to have octopus tentacles in numerous other libraries.
What am I running into here and how do I get this resolved?
My fix was to convert the projects to PackageReference as seen here: https://learn.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference The problem went away after doing this and I haven't seen it since. Still a little uneasy on why this happened... But I don't have time to dwell on it.
The Restore step fails in my build definition with this error:
error NU1100: Unable to resolve 'AutoMapper (>= 6.2.2)' for '.NETCoreApp,Version=v2.0'.
This is in a .NETCoreApp 2.0 that is using AutoMapper. Restore succeeds locally in VS 2017. Locally I am using dotnet sdk 2.0.0, and nuget 4.3.1. On the VSTS (cloud) server, I am specifying the latest nuget version, 4.5.0. I have tried many other versions, including 4.3.1 with no success.
I know there is an older, similar question here, but that was never answered satisfactorily, in my opinion.
If I look at the meta data in VS, at the top of one of the Automapper files I can see this:
Assembly AutoMapper, Version=6.2.2.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005
// C:\Users\randyg.nuget\packages\automapper\6.2.2\lib\netstandard1.3\AutoMapper.dll
From this you can see it's taking the netstandard1.3 version, which is correct. I'm wondering if the nuget on the build server is looking for a netcoreApp2.0 folder, rather than the netstandard1.3 folder? Following this theory, I tried adding this to my .csproj file:
<AssetTargetFallback>$(AssetTargetFallback);netstandard1.3</AssetTargetFallback>
My theory was this would tell nuget to look for a netstandard1.3 version of automapper if it couldn't find a netcoreapp2.0 version. However, this didn't have any effect. I later read that behind the scenes this fallback is already added automatically.
If anyone has any ideas I would greatly appreciate it. I'm pulling out (what's left of) my hair on this, as this is the only package giving me trouble, and it's a critical one for my project.
On the build server I'm using .NET Core sdk 2.0.3 as well, if that matters.
This is how I solved this: since it seemed it might have to do with my target being netcoreapp2.0, I tried adding an additional 'dummy' project to my solution, with its target = netstandard1.3. In this configuration, the restore/build succeeded. I thought I would have to maintain this dummy project for this purpose, until I tried deleteing it and now the netcoreapp2.0 solution still restores fine without it. I can only assume something was corrupted in the TFS build server NPM cache (even though I had tried checking the box to disable that cache), and once I got it to succeed once, it has cleared up whatever the issue was.
I am using TFS 2010 and VS 2012.
I failed in my attempt to upgrade MVC4 to MVC5. I thought I rolled back my project OK in TFS but my builds fail because the references to EF version 6 have not all been removed.
As far as I can tell I have removed EF v6 everywhere in my code. However in my build I have the following message;
Unified primary reference "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
Using this version instead of original version "4.4.0.0" in "C:\Builds\3\solutionA\solutionA- Test\Sources\projectB\projectB\bin\Debug\projectB.dll" because AutoUnify is 'true'.
Resolved file path is "C:\Builds\3\solutionA\solutionA - Test\Sources\MVC4\solutionA\solutionA.Model\lib\EntityFramework.dll".
Reference found at search path location "{CandidateAssemblyFiles}".
So what does "AutoUnify is true" mean?
Decided to make a proper answer from our comments. I think this initial problem was an out of sync dll, from the packages folder. You re-installed EF 5 fresh were still having packages issues.
This appears to also be something with your Nuget setup. This SO article is the same error as your latest build error. Build cannot find entity framework .
In particular this article from the accepted answer sounds very similar to the issues you're having. http://msmvps.com/blogs/rfennell/archive/2011/10/17/using-nuget-and-tfs-build-2010.aspx especially to your point that it works locally, but not in the build process. Let me know if your issues seems different.
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.
I finished a Netbeans project a few months ago, it was successfully done, finished. But the strange thing is today I happen to look into it and recompiled it, haven't changed anything, but got the following error, I vaguely remember I encountered similar situations before, just recompile and it will be fine, but not this time, I recompiled a few times, same error, restarted the PC, and recompiled again, same error :
build-impl.xml:501: copylibs doesn't support the "indexMetaInf" attribute
I never touched this file and have no idea why it worked fine, but failed this time, what's wrong and what's the fix ?
It seems that the problem is in version of Ant and new Ant attribute indexMetaInf.
I have the same problem and think it'll be worth to explain how I've got it.
How to obtain the problem:
I use NetBeans 6.8.
Recently I installed NetBeans 7.0. Just for acquaintance with new features.
I accepted to use old NB6.8 configuration, when NB7.0 asked me on the first launch.
That was mistake!
So. I started NB7.0 and my good old NB6.8 projects were there, in the projects list.
The problem is that NB7.0 not only imported my old projects in its projects list; but also
changed build-impl.xml of those projects.
And when I opened my projects in NB6.8 and tryed to compile them, there was that error with "indexMetaInf".
The essence of the problem:
In NB6.8 the Ant 1.7.1 is used, by default. And it seems that attribute "indexMetaInf" is only supported by
latest versions of Ant (maybe starting with 1.8.x). That new version of Ant was installed with NB7.0 and is used by NB7.0 only.
NB6.8 doesn't see it.
How to fix the problem:
I updated build-impl.xml file from subversion and it fixed the problem.
In my previous version of build-impl.xml there was no indexMetaInf.
Had the same problem, fixed it by copying the file org-netbeans-modules-java-j2seproject-copylibstask.jar from [netbeans]\java\ant\extra into the directory myProject\lib\CopyLibs
Strange thing happened again, this time good. I had a backup DVD, from a few weeks ago, I copied the project back, now it's compiling fine again, seems to me the project somehow got corrupted, I did a C: drive defragmentation last week, could it somehow moved some files around and messed up a bit ? Anyhow, not a problem now.
What platform are you using? I've had some odd errors like that on Unix due to trying to compile the project from the command line and having a older version of ant in my path.