I have got a solution consisting of 10+ projects. I am mainly responsible for one of these projects, which is basically a DLL, being called by other subparts of the solution. I would find it better to change the C# version from 7.0 to 7.1 - or to the latest - for some reasons.
I have got two questions:
Can the different versions of certain sub-projects cause any trouble
in the future?
Do you consider changing C# version to the latest a good practice?
Thanks for your help in advance.
Changes for incremental version updates should not be much of an issue.
If you use a source control system, which you should, then it will be relatively trivial.
create a separate branch, change the version of all projects.
if you use TFS, if I remember correctly, as I haven't touched that in many years, you simply check out the files and if anything goes wrong, you undo the edit actions.
Related
I have a C#/VB .Net Class Library which is used in multiple projects.
One of the issues we face is if a change is made to this Class Library it needs to be deployed to multiple projects.
As you can imagine, one project could be left out and this causes the application to stop working if the dll isn't the latest version. Sometimes this comes down to checking the version number of the dll and if it's not the correct/latest version it needs to be replaced.
The problem is sometimes the version is not incremented on the Class Library project which could mean for each of the project/applications the fix has been implemented but the version is now giving a false reading as it wasn't changed during development.
Is there a way to increment the Class Library version once development has been completed without relying on it to be done manually?
Is there an automatic way to increase/set this? We don't want it where it's increased every time we build, only once development is complete?
Any other better ways to tackle this?
I would suggest you to create a nugget package of your class library. and you can easily maintain the versioning. so if you want a few applications to use a particular version you use that if you want a few applications to use another version you can easily use it by updating to a particular version using NuGet package manager in visual studio.
I have been working on a C# project, being built under a Windows 7 Ultimate VM, under Visual Studio 2017. Yesterday, when updating my tool set, I was notified that there was a .NET Framework upgrade available, version 4.6.1 (previously utilizing 4.5.2). After the upgrade was complete, with several issues along the way, that I had attributed to recent networking issues with VirtualBox and a handful of other, different VMs lately, I found that my VS C# solution now had nothing available to open in the solution. This was after selecting an option where VS asked whether or not to use the new .NET Framework version, or remain with the previous.
First I had tried the new version (twice), and looked for other solutions that might exist under different menu options, then proceeding to the option of utilizing the previous version. Both had the same effect. I wasn't able to resolve the problem by importing the repository back from GitHub, either.
Obviously, at this point, I'm trying to find a way to get my solution to open, so that I can continue working on my project. I'm in the process of restoring my system to a point before the upgrade, but I'd like something a little better than that, hopefully. I haven't been able to turn up anything on here, or with general googling about this problem, unfortunately. Not really sure where else to go with the research on this. Does anybody have any ideas (or resources for me to examine better) that may help out with this issue at all? Anything is greatly appreciated!
You updated the .NET Framework runtime, but to develop against it you also require the Developer Pack for the updated version which contains the reference assemblies and documentation for Visual Studio.
Here's a detailed description from Hans Passant what exactly the developer packs are for.
I using new Amazon SDK that uses their latest dll. I can't replace the existing (old) referenced assembly/dll because some the old applications are based on it and most its functions are already depreciated. My colleagues never updated their applications. My problem applies to all other applications not just the one's that uses amazon but oracle,ajaxtoolkit,EF, so on and so forth. I always develop my application with the latest assemblies and every time I pushed it to production some applications would fail. I'll be lucky if redirecting it to a newer version can make it work but most of the time I have to recode and use the old assembly which I am not a fan of. Is there a way that I can point my application to use different dll or bin location? I am seeing some codebase config in web.config but I'm not sure about it.
I really need this..Every time I tell them to update their application and library they always complain..I can't do anything they are my seniors here.
Thank you in advance
You can try bindingredirect in web.config, although this works when you have multiple versions of same assembly. Not sure if it can help in your case.
See various examples here - https://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.110).aspx
In one of my previous threads someone said this was possible, so I did research. I couldn't find anything relevant, can anyone say how to do this, if it is possible?
Set the property of every referenced dll Copy Local=true
I can see from your other post that the framework you are referring to is the XNA framework.
You're really not supposed to be distribute Microsoft DLLs as loose files! You're supposed to distribute the XNA redistributable only!
Using the DLLs without installing them properly can lead to various problems on end-user machines. And distributing them as loose files is against the EULA!
Speaking as a Microsoft MVP for XNA (yes, we still exist, for now):
The official word from Microsoft is that XNA is still "supported". Basically this means that XNA is not suddenly going to break!!!
The XNA framework installer will remain available from Microsoft's website. (Just like, for example, this decade old framework download). You'll still be able to reference it from your installer (eg: ClickOnce). But, if you don't want to require the download, you can distribute the installer yourself (hence: "redistributable").
It will still install successfully on all current versions of Windows. And should continue to install on future versions of Windows.
The recent hullabaloo you may have heard about XNA is simply that Microsoft has made it public that XNA is no longer in development. All this means is that there will be no future versions. The existing versions will still work!
I would like to customize an off-the-shelf software that has a Lite Edition and an Enterprise Edition. The features are almost the same so that my extended customizations can work for both, but I have to recompile for each version because they have different version assemblies.
Can someone help advise me on how maintain this? I am using Visual Studio 2008 and Visual SVN. Should I create 2 completely different solutions, create one solution with duplicate projects, or create branches? Branches seem like the elegant route, but what is the idea? Create a "Lite Version" and "Enterprise Version" from the trunk... with the trunk being the "Lite Version"?
It depends on how much your code differs between the two. In the best case, if it's simply a matter of linking to different assembly versions, use NAnt or similar and simply create a build target for each one.
If life isn't quite that utopian, I'd create three projects on one branch: one class library to contain all common code, and another class library per version that only contains unshared code.
If the shared code has dependencies on those multi-version assemblies, though, you're more or less stuck doing things manually, as far as I can tell. That means maintaining a branch-per-target and doing regular merges between them to keep shared pieces in sync. Using a distributed CMS would ease the pain of merging, and creating a battery of unit tests will help reduce the amount of error these cross-project merges introduce.