I added Moles to a project in VS2010, decided I didn't want to use it and then removed the Moles reference and the .behaviours and .moles assemblies. The problem is that I repeatedly find Moles has been readded to the project with no intervention from me. Is there some kind of setting external to a project that will auto-add it if it's installed?
Be sure you have done the following:
Remove the references to the moles assemblies (e.g. "MyAssembly.Moles")
Remove reference: Microsoft.Moles.Framework
Remove all .moles files (toggle the "Show all files" button in the solution explorer -- you must select the test class before doing so)
Delete the "Moled Assemblies" folder
Clean the test project (right-click the project in Solution Explorer, and then select Clean)
Rebuild the test project
Bask in the glory of a Moles-free test project
UPDATE (2 JULY 2012)
I recommend shifting to .NET 4.5 Fakes and Stubs (currently in Release Candidate version). Fakes and Stubs are the productized version of Moles, and are fully supported.
Related
In my newly created BizTalk 2020 Dev environment when I'm adding a BizTalk Server Application Project (.btaproj) to the solution, the dialog window where you set the name of the project is showing the .NET framework selector and it defaults to version 4.7.2 as expected.
However when the project is added to the solution I can see in the properties for the project that it is targeting .NET 4.6.1. Has anyone seen this? is it a bug or something wrong with installation?
Naturally I change it to version 4.7.2 as the regular BizTalk project and everything compiles fine in Visual Studio.
But on our build server the same project fails. We use Azure Devops for CICD.On the build server we have the same version of VS installed (2019 enterprise) and BizTalk Server Extention (v3.12.1.0) is installed as well as msbuild tools from BizTalk server installation.
In the logs I first get a Warning:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3274: The primary reference "A.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.7.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.6.1". [B.btaproj]*
And further down in the log the btaproj will not find the assemblies to include in the .zip package.
Message above implies that I have different target versions but I don't.
Now the strange thing is that I can log on to the build server and clone the same project and compile it with VS just fine.
The only way to make the build server compile the project successfully (or any other BizTalk project with .btaproj for that matter) is to change .NET to 4.6.1 (for both .btproj and .btaproj) and it all compiles nicely and deploys to BizTalk environment.
I have checked project files and files checked in to Git and everything seems OK with the sources files. The clean flag I set to clean sources and output directory. I Can compile a regular BizTalk project and .NET application with 4.7.2 on build server just fine it's only when I involve a .btaproj project where it starts to misbehave.
Can anyone point out where to start to look? the .btaproj seems fishy to begin with but it can also be isolated to the msbuild on build server and it differs from compiling with Visual Studio.
Since the BizTalk Server Application project e.g .btaproj defaults to target framework moniker 4.6.1 when added to the solution you will need to manually change the version manually for BOTH debug and release.
Do not get misled by the create project dialog where it defaults to version 4.7.2
As a workaround ,you can specify /p:TargetFrameworkVersion=v4.7.2 in the MSBuild Arguments column of the MSBuild task.
MSBuild lets you set properties on the command line by using the -property (or -p) switch. These global property values override property values that are set in the project file. This includes environment properties, but does not include reserved properties, which cannot be changed.
For details ,please refer to this document.
I have 2 projects: A & B that I want to publish as NuGet Packages but I don't know how to develop efficiently in Visual Studio.
Solution 1
Project A
Project B - references Project A as NuGet reference
When I make a change to Project A that is needed in Project B do I have to publish Project A? Is there a way to get the project reference functionality during development? Maybe Project B shouldn't reference Project A via NuGet?
There must be a good way to handle this situation, no? I've reviewed the NuGet docs but I couldn't find anything. There must be docs/blogs/SO posts to read more about this... I'm struggling to come up w/ the right keywords.
You might want to look at this extension: NuGet Reference Switcher for Visual Studio 2017
This allows you to switch between NuGet packages and project references during development.
Check out this blog post: https://markheath.net/post/multiple-nuget-single-repo
Basically, dotnet pack handles this for you automatically. You use regular project references when developing.
There must be a good way to handle this situation, no?
The best solutions is that the project-to-project reference should be recommend when the referenced project is modified frequently, the nuget reference is more appropriate when share the reference project to others or publish it. Just like NuGet Reference Switcher doing.
For some more detailed info, you can check following thread:
nuget packages in local work
NuGet has many advantages as a package manager for the Microsoft
development platform, this does not mean that it is not flawed. Just
as you encountered, if the referenced project is modified frequently,
we have to rebuild it, build nuget, publish it for each modification.
That will bring a lot of boring work. To resolve this disadvantages,
the Project-to-project references should be a better way.
The
advantage of a project-to-project reference is that it creates a
dependency between the projects in the build system. The dependent
project will be built if it has changed since the last time the
referencing project was built. A file reference does not create a
build dependency, so it is possible to build the referencing project
without building the dependent project.
You could add following Post-build event command to pack your project after building.
"the nuget.exe path\nuget.exe" pack "project path\NuGetPackageLibrary.csproj" -OutputDirectory "Your target path"
When your build successful, the package in target path will be replaced by the latest version.
I have a solution with about 5 projects including a Silverlight client.
Through NuGet, I add the Async Targeting Pack for VS 11 at the solution level and select all projects.
It adds a reference in all the non-Silverlight projects, but not the SL one. The workaround is to add the reference by hand.
Is this a failure of NuGet? A failure of the NuGet package? Or am I doing something wrong?
Same thing occurs with Caliburn.Micro and the SL package.
Yet if I start from a fresh clean project, it all works as expected.
I tried deleting the .nuget and package folders, and manually removing the project reference, and that seemed to clear everything out, but I still had the above issues when adding the packages back in.
Greg
Which version of Silverlight are you using? I noticed the NuGet package only targets NET40, NET45 and SL5, so if you're using Silverlight 4, the reference won't be added to your SL4 projects.
I have a project that is build with cmake. In my cmakelists I have a
add_subdirectory(externals/foo)
to build the dependency "foo" which has it's own cmakelists.
Now it is so that also the whole foo sources and headers are included in the generated Project file (I'm using Eclipse). But all I want is to only have my project available in Eclipse (Eclipse has problems with subprojects in the same folder structure).
So that the cmakelists from "foo" is only used to build "foo" automatically and link it to my project. I don't want to see it in my IDE however.
Is this possible? If yes: How?
When I use Eclipse with CMake, I create the Eclipse project manually (with the New Project wizard) and for CMake I use the standard makefile generator. It requires a little extra setup: you need to set the build directory in the project properties if you're doing an out-of-source build, and I usually set the build command to make VERBOSE=1.
I'm not sure since I haven't used the Eclipse generator(s), but for the lack of a better solution, perhaps this method would solve your issue, since it gives you more control over the Eclipse project.
No, how should the ide know what to compile if you don't tell it what to compile? If you don't want to have the project in you project file, just don't add it.
Just compile the external lib by itself (use "cmake externals/foo") and then add the libraries in your project's CMakeLists.txt with
target_link_libraries(your_project externals/foo/bin/foo.lib)
Im trying to compile a simple class library project,its from Source Safe.
However,when i "build" project,then right click on project's BIN --> DLL --> Choose Properties,the Date modified doenst change,and i dont know if the DLL was recompiled with the new version.
Any ideas?
A few things:
1) Build won't recompile the dll if you haven't changed the source. If you want to forcibly recompile, use Rebuild or choose Clean Solution before building (cleaning deletes the old assembly).
2) Check to see whether you're looking at the correct build directory. By default, .NET comes with two configurations: Debug and Release. Each configuration has its own directory: e.g., \Bin\Debug\*.dll. Visual Studio only updates assemblies in the current configuration directory.
3) If you still can't tell whether your dll has changed, you can download Reflector and inspect the file.