We recently split our current work into two different VS solutions, one which contains mainly the front-end stuff (aspx files, user controls and the like) and the other which contained mainly business logic to compile into assemblies and reference in the first solution.
Since doing this we've been experiencing problems with versioning when building the business logic solution and trying to check the new dll's into the front-end solution. Most of the dll's (and pdb files) say that a newer version exists on the server.
I'm confused about this because when I went looking in the AssemblyInfo files of the projects in the Business Logic solution, they all had no version number set except the default of 1.0.0.0. Building the solution is currently generating files with version 2.2.1.3 and the server apparently has version 2.2.2.3 but nowehere can I see where these version numbers are being generated. Changing and rebuilding a project doesn't seem to change the version number unless I manually edit the version number in the AssemblyInfo of that project.
Can anyone suggest a way we can move forward on this, so that all the projects in the solution automatically update to the same version number when the solution is built, regardless of which developer is doing the build?
Cheers,
matt
The version number has nothing to do with the version number in the dll, but with the version of the file in source control.
You are trying to check in a file from which you don't have the latest yet. So undo your change, get the latest version of the files. Then check them out again and check them in.
Related
We have recently taken over a project from an outsourcing company. This project uses Moles and Pex for unit testing, but since we have not had the project for long, I am not very familiar with the frameworks.
That being said, we are busy upgrading this project to run in .Net 4. I have resolved most of the issues that have jumped out, but there is one that I cannot get a handle on. Some of the unit tests cannot compile because of the error:
Could not load file or assembly 'Example.Assembly, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
The part that baffles me is that it is a project reference and the assembly is being copied to the output directory of the unit test. Most of the other project references are found and I cannot spot any difference between the ones that work and the ones that do not. I am not sure if this problem has to do with the pex/moles frameworks, but I thought I would mention it.
I have tried the usual things of removing and adding all the references and regenerating the moles assemblies.
Has anyone else run into this problem? Any help would be greatly appreciated.
EDIT1: Ok, after some more investigation into the build output, it appears as if it is not moles, but the .accessor files that are not generated correctly. I get the exact same problem as asked in Unit test project cannot find assembly under test (or dependencies), but unlike his problem, mine does not go away after deleting the accessor.
EDIT2: Turns out is is a program called Publicize.exe which falls over with that error. Still no idea why though. Looking at Fusion logs is looks like it does not search under the working directory for the dll that it is trying to generate the accessors for. Running it manually on a bunch of assemblies from our solution, I find it works on some, but not on others. I have not been able to identify a difference between the ones that work and the ones that don't, though.
Thanks
Ah, yes. I have read this story many times, and have the tee shirt. I run through my usual Moles first-aid kit, when encountering any issue, including this one.
Perhaps, this question will provide some help: Am I the only one getting "Assembly Not Available in the Currently Targeted Framework"?
Ensure the Moles framework is properly installed on the workstation and/or build server
Ensure the Moles assemblies are being built (see the excluded "Moles Assemblies" directory)
Check your build profile -- it may need to be set to full framework profile
Triple check your output destinations and post-build commands -- I have seems some solutions that copy the output to another location
Try using the Visual Studio Pex/Moles extension, if you are not already doing so
An invasive fix-all process is to simply create an all-new solution, projects, and test projects, and then copy the existing code files into them. It's surprising how many issues can be resolved for various project-related errors. Basically, a hard reboot for the entire solution.
Since you are updating to .NET 4, you may as well go to 4.5, and used the productized version of Moles, called "Fakes". You'll find Fakes in the Visual Studio 2012 release candidate. This significant feature hasn't received much attention.
I am building an app for windows phone sdk 7.0 and 7.1, I want to have some extra features for 7.1, but I want to maintain only one code base for both, and only have some code appear if user's phone is 7.1.
I read about Shawn Wildermuth's post: http://wildermuth.com/2011/08/23/Maintaining_a_Project_with_Two_Windows_Phone_Versions. But I am not sure how to do "First off, I took my original project and created two solution folders and created the 7.1 projects as shown here" mentioned in the post.
Could someone help? or suggest other ideas?
Thank you.
The perfect solution is preprocessor directives
[Updated 11/5/2011: removed outdated information about the Marketplace. Thanks for the udpated info #johnforrest]
To do what Shawn is describing take your existing solution with your existing 7.0 project(s). Add a solution folder and name it "7.0". Move your existing 7.0 projects into that solution folder. Make another solution folder named "7.1". For each project in the 7.0 solution folder, create a new matching project in the 7.1 solution folder. These are Shawn's PhonyTools.7.1 and so on. Now follow his directions for populating the 7.1 projects with linked files that are linked from the 7.0 projects.
I find linked files to be a blessing and a curse. If you open the linked file in one project and edit it, Visual Studio does not alway know that the other project containing the linked file needs to be rebuilt. Lately, I've been finding that if I remember to then open the linked file in the other project I will get a warning that the file is opened in another project, but then VS recognizes that the file has changed and will rebuild the other project.
Preprocessor directives, as suggested by #KevinDTimm, don't solve the problem all by themselves, because you still need two different projects for the two different types of projects (7.0 and 7.1 apps or libraries). Additionally the different versions of the apps will reference different corresponding versions of assemblies.
Lastly, while we're on the topic of conditional compilation, don't forget the Conditional attribute, which is often a much better solution than using preprocessor directives. Bill Wagner gives a good description of the merits of the [Conditional] attribute in Effective C#, 2nd ed., item 4, p. 20. Enjoy!
I'm looking for general advice. I created a Visual Studio 2010 project that outputs an ocx file that is used on XP and Vista machines. The DLL on which it depends has been updated on our Win7 machines. I simply needed to rebuild for Win7 using the exact same code with an updated .lib file. I created a second project configuration (ReleaseW7) and it only differs from the original project config (Release) in that it points to the new .lib.
So now I have 2 files both named xx.ocx. Besides looking at the name of the folder each file resides in (or looking at the creation time of each) there is no way to determine which is which. I thought of using different file version numbers but as far as I can tell (and I'm relatively new to this so I could certainly be wrong) that would require two separate projects each with a slightly modified resource (.rc) file, instead of simply having two configurations within the same project. If nothing more, that seems like a waste of hard drive space. It also feels like the "wrong" way of using file version numbers
Is there a cleaner or more "standard" way of handling this? All I really want is a way for the folks who install the ocx and support the end user to know for certain that they are working with the correct file.
Long story short, I decided to use different version numbers. I was able to setup a preprocessor definition for the resource compiler and use that to handle different versions of VS_VERSION_INFO in my .rc file.
In case anyone is interested, this is the resource I found:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/605275c0-3001-45d2-b6c1-652326ca5340/
I have a Java background so I’m used to having Maven handle all problem around downloading and keeping dependencies up to date. But in the .NET environment I have not yet found a good way to manage all these external dependencies.
The main problem here is that I mass produce solutions and they all tend to depend on the same third party dll’s. But I don’t want to maintain separate copies of each component under each solution. So I need a way of linking all the different solutions to the same set of dll’s.
I realized that one solution might be to include the external libraries in a ”library project” that is included in all solutions and let the other projects references them through it. (Or just make sure to reference the external dll’s from the same place for all projects.)
But are there any better ways to do this?
(Preferably using some sort of plug-in for Visual Studio.)
I’ve looked at the Visual Studio Dependency Manager and it seems like a perfect match but have anyone tried it for real? I’ve also seen the .NET ports of Maven, but unfortunately I was not too impressed by the status of those. (But please go ahead and recommend them anyone if you think I should give them another try.)
So what would be the smartest way to tackle this problem?
Update:
I realized that I needed to explain what I meant with linking to the same set of dll’s.
One of the things I'm trying to achieve here is to avoid that the different solutions are referencing different versions of each component. If I update a component to a new version, it should be updated for all solutions upon next build. This would force me to make sure all solutions are up to date with the latest components.
Update 2:
Note that this is an old question asked before tools like NuGet or OpenWrap existed. If anyone is willing to provide a more up-to-date, please go ahead and I will change the accepted answer.
Find some place to store the assemblies. For example, I store the .Net core assemblies like so:
<branch>\NetFX\2.0527\*
<branch>\NetFX\3.0\*
<branch>\NetFX\3.5\*
<branch>\NetFX\Silverlight 2\*
<branch>\NetFX\Silverlight 3\*
Use the ReferencePath property in MSBuild (or AdditionalReferencePath in Team Build) to point your projects at the appropriate paths. For simplicity and easy maintenance, I have 1 *.targets file that knows about every such directory; all of my projects Import that file.
Make sure your version control strategy (branching, merging, local<->server mappings) keeps the relative paths between your projects & your reference paths constant.
EDIT
In response to the update in the question, let me add one more step:
4) Make sure every assembly reference in every project file uses the full .Net strong name and nothing else.
Bad:
<Reference Include="Microsoft.SqlServer.Smo">
<SpecificVersion`>False</SpecificVersion>
<HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>
Good:
<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />
Advantages of the latter format:
Using a HintPath in a collaborative development environment will inevitably lead to situations where "it works for me" but not others. Especially your build server. Omitting it forces you to get your reference paths correct or it won't compile.
Using a weak name invites the possibility of "DLL hell." Once you use strong names then it's safe to have multiple versions of the same assembly in your reference paths because the linker will only load ones that match every criterion. In addition, if you decide to update some assemblies in place (instead of adding copies), then you'll be notified of any breaking changes at compile time instead of whenever the bugs start coming in.
Adding to what everybody else is saying, it basically comes down to two things:
Making sure that all developers have the same versions of external libraries
Making sure that all developers have the external libraries located in the same place (at least, relative to the source code)
As Richard Berg points out, you can use ReferencePath and/or AdditionalReferencePath to help solve #2. If you're using msbuild in your build process (in our case, we're using CruiseControl instead of MS Team Build), you can also pass ReferencePath to it on the command line. To solve #1, I've found svn:externals to be useful (if you're using SVN).
My experience with Maven is that it's way overkill for most purposes.
I usually have a separate folder structure on the source control for extrenal or Internal dependencies, and these filders have the assemblies according to build or version number for example
public\External\libraries\Nunit\2.6\
or
Public\Internal\libraries\Logger\5.4.312\
and inside the solutions all the projects that need to use any of the dependencies just adds a reference to that assemblies in the public internal or extrenal folders.
We have multiple projects in VB 6.0. Most of these projects are ActiveX DLL's. When developing, projects take a '.dll' reference of other projects, but this does not allow us to debug. So, for this we have to take a reference to the '.vbp' project. However, taking a project reference, means we are asked for binary compatibility.
During development, should we use project compatibility and build projects into DLL's for deployment?
It's fine to reference the vbp during development, just make sure you keep binary compatibility on. If you do not, you'll make the registry into a nice mess and deployment will be a disaster. Keep in mind, however, even with binary compatibility on, every time you change the public interface of the DLL, you're creating a forward reference in the OLE entry in the registry.
we have four levels of DLLS in the CAD/CAM software we use for my company's cutting machines. We handled this by making a compatibility directory that the PREVIOUS version's DLLs in it. With this we can continue to use binary compatibility.
The process looks like this.
Compatibility has Revision 119 DLLs
in it.
We compile down Revision 120 and
release it
Copy the Revision 120 DLLs to the
compatibility directory.
Develop
Test
We Compile down Revision 121 and
release it.
Copy the Revision 121 DLLs to the
compatibility directory.
[repeat]
The main problem you need to watch out for is changes to the the lowest level of DLLs you use. Visual Basic 6 uses a #include statement in generating its internal type libraries. Doing will need to getting it confused over whether it is still binary compatible or not. Note you can see this by using the OLE View tool that comes with Visual Studio 6.
The solution to this problem is compile the low level DLL and immediately put it into the compatibility directory. The resulting internal typelibs for the higher level DLLs will now properly detect whether you are binary compatible or not.
Remember binary compatibile means all you can do is add a method or property. You can't change a existing method's name or argument list. (it's signature in COM terms)
You should be able to debug referencing a dll. Did you start the projects in the right order? Or you can add all/some dll into the same "Project Group" (*.vbg).