I am running Visual Studio 2015 (Update 1, .NET Framework 4.6.1) and all designer files stopped auto-updating in my project. In the past I used to have this happen with one file and I would simply recreate the designer for that one file, but I never had it happen on the project file like this.
Some solutions say to go to C:\Windows\Microsoft.NET\Framework\v4.0.30319 and then your projects folder and clear all temp files, but none of my project's folders are in here.
Microsoft Visual Studio Enterprise 2015
Version 13.0.24720.00 Update 1
All of the latest .NET Frameworks installed (4.5, 4.6, 4.6.1)
Everything is fully up to date
The only fix that I found was to take a backup of my project and re-create it as a new project.
In my case I just took a backup of my local non-working project got latest from source control which created a new project.
It definitely has to do with visual studio files being out of sync which causes locking of the designer files.
Related
I recently moved from VS 2019 to VS 2022 and installed setup project extension for VS 2022 version:
https://marketplace.visualstudio.com/items?itemName=VisualStudioClient.MicrosoftVisualStudio2022InstallerProjects
The problem is that when I install binaries now, all files in the installation folder have the current date/time (with VS 2019, only the modified DLLs / EXE file would have the current date/time, all other DLLS [from 3rd party libraries] would retain their original date/time).
I have tried to uninstall & re-install the extension + delete and recreate the setup project, to no avail. These are 64-bit Winform apps, .NET 4.6.1.
The csproj & sln files are identical, so it is unlikely that the problem is related to those files (or the project references, since they live in the csproj files).
Also, I tried opening the solution in VS 2019 again (even though the setup project extension is only for 2022) and it built and installed fine, without changing the timestamp of all the files.
How can I make this work with VS 2022 so that when I install new binaries, only the modified files get a new timestamp?
I propose you do to use e.g. lessmsi and check how the file got
packed into the .msi. While this may not provide the final answer to
your question, it will tell you about the root cause of the issue.
I ran into the very same issue. My case also is a WinForms App,
targetting .NET Framework 4.8, same issue. The following screenshots show the binary in question extracted from the .msi: VS2022 setup project packs with changed time stamp whereas VS2017 setup project preserves time stamp.
So in my case the issue apparently is caused by the VS2022 setup project which packs with changed time stamp. I have created a ticket at Microsoft, hoping they get this issue fixed.
Discovered to my horror, that after updating all my Visual Studio 2017 instances to version 15.5 (from version 15.3), none of the setup projects will load and I get a message saying they are not supported. I've tried several Desktop applications, all developed in VS2017 and these setup projects won't load.
Is there any workaround to this (without creating all new Setup projects - some are quite complex)?
Ah, the issue turned out to be that the Installer Projects extension was corrupted, so I renamed my setup project, then re-downloaded/re-installed the "Microsoft Visual Studio 2017 Installer Projects" extension, closed Visual Studio, renamed my Setup project to what it was, opened the solution again & added the Setup project back to the solution.
NOTE - the other PC running VS2017 never had the Installer Projects integrated w/VS in the first place (it was more for web development), the reason why they wouldn't open.
Worked like a charm!
I have had a project in VS 2015 Update 3 with a lot of code logic behind. I upgraded it to VS 2017 RC successfully. The code implementation went on and on until getting to the point where VS 2017 RC exhibited a lot of issues and instabilities e.g. .Net Core DLL template removed! by installer or Resource file could not be compiled and so forth! I'd like to revert the solution back to VS 2015 to keep working flawlessly but it's impossible easily due to a lot of code implemented in VS 2017 excluding new Roslyn features. Any suggestions how to perform the downgrade?
You will also need to update your *.vcxproj files, to change the toolset referenced there to the one used by the earlier compiler.
What I found useful, is to create a small scratch project (just simple console app) in each version of visual studio, then use beyond compare or similar to contrast the .sln and .vcxproj files from each vs version. This will show you the toolset changes and maybe a few others that you need. For example going from vs 2017 to vs 2019 the toolset changes from 141 to 142.
So the lines
<PlatformToolset>v141</PlatformToolset> are for vs2017
and
<PlatformToolset>v142</PlatformToolset> is for vs2019
It's indeed a manual process and no there are no tools that can automate that.
I had the same problem and i fixed it using this solution:
1) create a solution of whichever project you want (winforms, etc)
2) browse to your project folder and find your .sln file.
3) open it using notepad.
4) copy the first 4 lines as shown
here.
5) find your .sln file for the project you wish to downgrade. for example : foo.sln (its found where your project is).
6) open it with notepad and paste the lines instead of the first 4 lines
7) save and open the sln. it should open it under visual studio 2015
i hope this works for you
In short: I need to open an application originally built in Visual Studio 2008 (version 9) in Visual Studio 2013 without upgrading the project since the overall project architecture must remain the same for when I check it back into source control.
Details: I need to open a Visual Studio solution (.sln) inside Visual Studio 2013. The solution in question was originally developed in Visual Studio 2008, so when I try to open said solution in Visual Studio 2013, I am shown a prompt with the projects within the solution checkmarked, with the message:
These projects are either or supported or need project behavior impacting modifications to open in this version of Visual Studio. Projects no displayed either require no changes or will automatically be modified such that behavior is not impacted. Visual Studio will automatically make functional changes to the following projects in order to open them. You will not be able to open these projects in the version of Visual Studio in which they were originally created.*
My attempt at a fix was to just upgrade the solution and hope for the best. This is successful, but after building and attempting to run the main project, I see the following build error:
The type 'Microsoft.Web.Services3.WebServicesClientProtocol' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. *
I then tried both commenting out the references to this assembly and adding in the missing reference. Okay, so then I rebuilt the solution and attempted to run. Same error, but for a different assembly. Repeat fix, same error for different assembly. This pattern continues and continues, and at this point I realize this is unacceptable anyway, because when I make a change to this solution, I need to check it back into source control. When others open it, they may be opening it in VS2008, and therefore this “upgraded” version is inconsistent with the version the business uses. I need to open the solution originally build in VS2008 in VS 2013 (can't work around this, needs to be VS2013). If it helps, I'm using 64 bit Visual Studio 2013 Ultimate.
Any help or guidance will be greatly appreciated!
As several of the commenters have already helpfully pointed out, this is not possible. Round-tripping (i.e., opening and manipulating project files created by an older version of Visual Studio in a newer version of Visual Studio) was not supported until Visual Studio 11. The only way to open a Visual Studio 2008 project/solution in a later version of Visual Studio will be to convert it.
As far as interoperability with previous versions is concerned, you have two options:
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then edit the code files. Once you're satisfied with your edits, commit only the modified source files, not the project infrastructure files. Your fellow developers, stuck on VS 2008, won't notice any difference.
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then rename the project file (e.g., by appending a -vs2013 suffix to it). Commit this to your code repository. You will now have two project files in your root directory, one for each version of Visual Studio that your team works with. From here on, you just open the project file corresponding to the version of VS that you have installed.
I used approach #1 for a good part of last year, where I spent most of my time developing a C++ application in VS 2010 on a desktop machine, but also wanted to work on it on my notebook running VS 2013. Of course, in my case, it took a trivial amount of time for the automatic conversion to upgrade my project file after pulling from source control. I didn't have to do any tweaking thereafter to get the project to build. It sounds like your case is different, so option #2 might be a better choice.
I have a Solution file (.Sln) in Visual Studio for my Application. Application development started back in .NET 3.0. Later it was decided to provide application in .NET 3.0 and .NET 4.0.
Since there wasn't an option (I was not present at that time) so two solution files were created.
App_NET30.Sln
App_NET40.Sln
Later came a requirement to support .NET 4.5 as well. So one more file was created
App_NET45.Sln
Respective Solution files are opened using Visual Studio version
App_NET30.Sln - Opened in VS 2008
App_NET40.Sln - Opened in VS 2010
App_NET45.Sln - Opened in VS 2010
Now, somehow, this does not seem a good way to me. There has to be a neat and clean way of doing this. Like doing it all in a single solution file
I tried to create a single solution and defined various build configurations in the file and changed Target Framework in each build configuration. But it did not persist.
What can be a way to have a single solution file and achieve all that I desire ?