I've recently taken over a project, and the original developer has gone. I'm now trying to install the app on a new server, and I've got a problem with dependent assembly versions.
The project is a reporting tool, with (unfortunately) a reference to Crystal. On my machine I have version 11.5.9500.313 of CrystalDecisions.CrystalReports.Engine.dll.
The NAnt script that does the build defines the references, including the Crystal dll, but does not define the version number.
When I build the app, using the NAnt script, and analyse the assembly with Reflector, the reference is for version 11.5.3300.0.
Can anyone explain where the version number of this reference comes from?
Assembly version (from AssemblyVersionAttribute) is not necessarily the same as the file version (from AssemblyFileVersionAttribute). Unless you use a tool which returns the assembly version consistently (e.g. Reflector) comparing versions is going to be completely unreliable.
It comes from the references in the vs. project file. Open the project file in a text editor and check it out. Anyway, to fix re-add the references in the visual studio.
Related
This is going to be one of those questions for which there are hundreds of answers, so please bare with me as I have tried most of them!
I have been breaking up a very large project into smaller components with the view to slowly migrate it all to .NET Core.
Some Projects in my solution are now .NETstandard class libraries, and there are also some .Net Framework (4.7.8) projects.
I was getting on quite well today when suddenly I started getting this:
Could not load file or assembly 'ServiceStack.Text, Version=5.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
The version installed in my projects is (was - read on...) 5.8.0.0
Now, I am not new to this error, I've found it before and it usually relates to either a project reference file, web.config or packages.config referencing a .DLL with a different version than that of the file in the /bin directory.
So I have been through all (34) project folders and deleted servicestack.text.dll in every project.
I have uninstalled it via NuGet in every project and reinstalled it.
I have checked every project's packages.config file and where they are .NETStandard projects, the project files and made sure that there are not references to ServiceStack.Text v 5.0.0.0
I have rebuilt, cleaned and restarted the solution, visual studio and my computer many times!
Then I noticed something...
In my .Net Framework projects, under References, if I click on the ServiceStack.Text file and view the Reference Properties, it shows Version: 5.0.0.0, but the Path is directing it at 5.8.0.0.
In the .NETStandard projects, it shows the correct version.
So then I thought maybe 5.9 can't work in the Framework projects, so I uninstalled it from every project and installed v 5.0.0.0 in every project. This then wouldn't build because Visual Studio threw errors in the .NETStandard projects saying "downgrade detected, please restore the updated version"
SO then I installed 5.9 (which is now the latest version) into all the .NETStandard projects, leaving 5.0.0.0 in the .NET Framework ones.
Now it will build, but the FileNotFound exception throws again when I try to run it.
So I have tried;
Everything using ServiceStack.Text 5.9
Everything using ServiceStack.Text 5.0
.NET Framework projects using 5.0 and .NETStandard (2.0) projects using 5.9
Uninstalling and reinstalling multiple times
Deleting all obj directories, cleaning and rebuilding
Checking all project and packages files
Wasted most of the day on this, so turned to SO... I do hope someone can help!
Right.... Answering my own Question again...
After a lot of messing about I found out what was happening, and it was nothing to do with Visual Studio builds, or .package file conflicts
The reason the error suddenly appeared was a call to Dump() in something I was testing, which had another call to Dump() in a preceding function referencing a different .NET Framework. Whilst according to Microsoft this (mixing Frameworks) works, ServiceStack has different versions and it caused a version conflict.
In case anyone else runs into this, here's what I have found…
Pseudo code example… a function in a .NET Standard Project (2.0)
Function Blah() as Something
… do something
Log(TestResult.Dump())
Return Something
End Function
And then a .NET Framework (4.7.8) Project which consumes this and again tries the Dump the result:
Sub DoSomething()
Dim Something = Blah()
Write(Something.Dump())
End Sub
The two frameworks require different versions of ServiceStack.Text and therefore throw a confusing, though I guess correct, FileNotFoundException in the running project.
I’m sure to run into this one again….!
I'm going to create my first managed plugin for Unity (2018.2) using Visual Studio Community for Mac (7.6.11 build 9).
I've read the documentation but I think that the step-by-step instructions are not meant to be followed on Visual Studio Community for Mac.
As you can see in the screenshot below, I've created several projects using each and every library template available.
All of them compiled successfully to a DLL targeting versions of .NET framework that are incompatible with Unity.
The only project I could change the .NET framework version to match Unity's 3.5 is the one based on the Other > .NET > Library.
Everything works fine but I'd like to know if the assumptions, the process and the final result are correct. Can you tell me, please?
I don't know the difference between the "Class" and the "Class Library" option but you're supposed to use the "Class Library" option. This is not the main point of this answer.
Two future issues you haven't solved yet:
1. Referencing Unity's API.
If you ever have to use any Unity library or API in youir plugin such as Vector3, you need to add Unity's UnityEngine.dll to your library settings. If you don't, you will run-time exceptions.
Go to Project --> Add Reference ---> Browse ---> Browse Button
then select <UnityInstallationDirecory>\Editor\Data\Managed\UnityEngine.dll. You can now build your managed plugin. Since you're using Mac, this path is different on your OS. On Mac, this could be /Applications/Unity/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll. You just have to find where UnityEngine.dll is located.
2. Invisible stack trace
With your current setup, if you run into error with your managed plugin, the stack trace won't be there. You won't have the file names and line numbers and this makes is very hard to debug your plugin code.
When you build the project, Visual Studio generates a PDB file instead of an MDB file. Unity can't use this directly. You have to convert the PDB files into MDB files.
From command line, run this:
<UnityInstallationDirecory>\Data\MonoBleedingEdge\lib\mono\4.5\pdb2mdb.exe UnmanagedPlugin.dll
Again, the path might be different on Mac, you just need to find "pdb2mdb.exe" that converts the PDB files into MDB files.
After that, copy the MDB and dll file into the "Assets" folder in your Unity project.
I have MFC Dialogue based applications written in VC++6.0. Due to my work environment requirements I need to upgrade to Visual Studio 2010. I don't need to add any new feature, just compile with the upgraded visual studio.
Can any guide me on this?
What are all the primary requirements and how to start it?
Just open the project/solution in VS-2010. Convert it and compile.
You might get some compiler warnings/errors depending on your code, because the new compiler is more precise.
But most conversions lead just to a view warnings, like security stuff and others and should work directly.
From the VC++ team blog and Visual Studio 2010 C++ Project Upgrade Guide:
With Visual Studio 2010, C++ build system moved from the VCBuild based system to the MSBuild based build system.
The C++ project system is also built on top of the MSBuild build system.
There are some limitations, known issues or by design changes that you may run into during the upgrade process.
VS2010 supports upgrading from VC6, VS2002, VS2003, VS2005 and VS2008.
As in previous versions of Visual Studio, upgrade can be done either through IDE conversion wizards or from the command line (Devenv.exe /upgrade).
Here are the recommendations for upgrading your applications:
1) Set up the upgrade environment the same as your build environment
The upgrade process will try to load files and evaluate values during upgrade. If your projects use values that are not defined by the project files themselves, for example, values defined by environment variables, it is required that these environment variables are set up before doing the upgrade. Without these environment variables properly set up, you may get conversion warnings or errors caused by unevaluated values.
2) Make sure you have the required platforms installed before doing upgrade
Converting a project on a machine without all the available platforms for the project will result in a conversion error. For example, if you try to convert a project with Itanium Platform on Visual Studio Professional SKU, which does not support the Itanium platform, you will see a conversion error like the following:
Failed to upgrade 'Debug|<Itanium>'. Please make sure you have the corresponding platform installed under
'%vctargetspath%\platforms\Itanium'. Cannot load the project due to a corrupt project file. The following error
has occurred during XML parsing:
File: D:\Sample\ConsoleApp\ConsoleApp.vcproj
Line: 28
Column: 5
Error Message:
System error: -2147154677.
The file 'D:\Sample\ConsoleApp\ConsoleApp.vcproj' has failed to load.
This is by design as the conversion needs to evaluate the properties in the missing platforms to do a successful conversion. You can verify which platforms are installed on your machine by looking in the following directories: %ProgramFiles%\MSBuild\Microsoft.cpp\V4.0\Platforms (or %ProgramFiles(x86)%\MSBuild\Microsoft.cpp\V4.0\Platforms on x64 machine) for the Platforms installed on the machine.
3) Use native Multi-Targeting to build against VS2008 toolset first if possible
In VS 2010, Native multi-targeting have been added which allows you to build against the Visual Studio 2008 toolset from within the VS2010 IDE using the new MSBuild-based project system. I recommend you to take advantage of this feature by using VS2010 to build against VS2008 toolset first when upgrading. This can help isolate any project system/build system related issues from the tools issues that you may run into after upgrade. This will make the move to the VS2010 toolset much smoother.
Upon upgrade, the property sheet files (.vsprops) are converted to their new format (.props). Likewise, project files (.vcproj) are converted to their new format (.vcxproj). Note, the new project files are generated alongside the old project files. A new file type (.filter.vcxproj) is also generated during conversion. The filter files contain the information that is used to display folders in the solution explorer. This filter information was originally part of the project file. This change was necessary because MSBuild requests a rebuild whenever the project files changes. By storing filter information in a separate file, the filter can be changed without triggering a rebuild of the entire project.
Note: Upgrade process will not convert the .user file. As a result, your debugging and deployment settings will not be preserved after conversion.
In VS2010, a new command line upgrade tool, VCUpgrade.exe is introduced. This command line tool is suitable for upgrading applications with only one project as it cannot take in solution file as input and parse solution information into project files. VCUpgrade.exe is located at: $(VSInstallDir)\common7\Tools directory. This tool will also be shipped in the next release of WinSDK so that the users can do command line upgrade of the project files shipped in WinSDK without Visual Studio IDE.
I have a VC++ project and I need to add a reference to a managed dll. This dll has a version number which changes every build. When I add it to my project, its version is saved and if I replace it with another one (with a different version number) the project cannot compile because it doesn't find the dll with the version previously saved.
Is there a way to add a reference without a specific version?
Thank you for your help
The C# IDE has the "Specific Version" property for a reference but the C++/CLI build system doesn't support that. There is a workaround, you can use the #using directive in source code to load an assembly reference. This by design cannot check the assembly version of the reference assembly. Normally that's a problem but not in your case. The MSDN page is here.
Note: I don't know whether this works with C++ projects -- we have C# code that references C++, but we haven't done the other way around. But just in case it's easy, I'll offer this:
With C#-to-C# references, normally you would make sure both projects are in the same solution, and then add a reference using the "Projects" tab of the Add Reference dialog (not the "Browse" tab). This way, the build system has a reference to the project in the solution (which knows its own current version number), rather than having a reference to the filename+version; and then it can cope with version number changes just fine.
I'm using VS2005 (haven't moved to 2008 because I'm still using some legacy tools) and have a question about the way project references work.
If I make a project reference to a project that has been deployed to the GAC, VS will use the assembly in the GAC. This is annoying when I have older code in the GACed assembly and I am making code changes and doing quick tests against them - I have to either GAC the new code every time, or remove the assembly from the GAC so VS can't get it from there.
Is there a way to defeat this behavior?
Can't you just change the reference, pointing to the DLL directly?
Better yet, if you changing your DLL, use the Project as reference instead of the GAC DLL?
The best way around this is a two step proces.
1.) In your GAC'ed DLL upgrade the minor version number. (1.0 to 1.1)
2.) Update the project reference to copy local, and use the new version number.
This "SHOULD" get it working, but with the GAC it isn't always 100%.
You could go the route of a policy file, to stop the GAC from loading....but that gets way more complex.
Copy the reference locally.