I'm getting some annoying errors from Visual Studio Designer when trying to open one of my forms (Could not load type x from assembly y, even though assembly y clearly contains type x; the project builds and runs fine). It looks like Visual Studio Designer cache issue to me. I looked around and it seems like Visual Studio Designer uses a ShadowCache, normally found at
C:\Users\%UserName%\AppData\Local\Microsoft\VisualStudio\15.0_6d397e1a\Designer\ShadowCache
However, that folder is empty. This suggests to me that there must be some other cache location, since I am using designer for some other things, there should at least be something in the designer cache location...
To clean windows forms designer project assemblies, you need to delete subforlders of ProjectAssemblies folder which is located in %userprofile%\appdata\local\Microsoft\VisualStudio\ under one of the folders depending to your visual studio version and edition.
For example for me:
%userprofile%\appdata\local\Microsoft\VisualStudio\15.0_a26f780e\ProjectAssemblies
If you look in the folder, you see subfolders containing assemblies of your projects.
Related
I am developing a Visual Basic project in Visual Studio 2010 that uses ArcObjects. (I have ArcGIS 10.3 for Desktop.) I am getting the error "'RuntimeManager' is not declared. It may be inaccessible due to its protection level." A previous answer, Esri ArcObjects--Esri.ArcGIS.Version assembly, recommended adding a reference to Esri.ArcGIS.Version by clicking on Project, Add Reference, selecting it under .NET and clicking OK. I have tried to do this, but it's not under .NET. What can I do to make it available?
You should be able to find it if you use the Browse option.
The ESRI.ArcGIS.Version.dll file should be under your DeveloperKit installation folder. For me it is:
C:\Program Files (x86)\ArcGIS\DeveloperKit10.2\DotNet
I have a Visual Studio 2013 solution, and I would like to make it work with Visual Studio 2005. How can I downgrade the solution file?
I noted this line in the .sln file:
MinimumVisualStudioVersion = 10.0.40219.1
However, changing this line to 8.x.xxxxx.x, lower than my Visual Studio version number, still failed with the same error.
Open the .sln and project files with a text editor, Notepad will do fine. The .sln file is the easier nut to crack, it has not changed much over the years. You'll see something like this at the top of the file:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
VisualStudioVersion = 12.0.21005.1
MinimumVisualStudioVersion = 10.0.40219.1
Followed by a list of the projects and the configurations. The "Format Version" is the most important value, if it is a mismatch with the VS version then it will quickly fail to load the solution. Values are 8.00 = VS2005, 9.00 = VS2008, 10.00 = VS2010, 11.00 = VS2012, 12.00 = VS2013
The lines that mention the VS versions were late additions, first added in VS2012 to support the feature where VS can open old projects without having to upgrade them. Just delete these lines.
Then you'll have to tackle the project files, they are certainly the harder nut to crack. You did not mention the language you are using, it does matter rather a lot.
First off, if this is a C, C++ or C++/CLI project (high likelihood given the request) then stop right now. Versions of Visual Studio prior to VS2010 used a non-standard build system for those languages, driven by the VCBuild.exe build tool. The .vcproj file format was very different and does not resemble the later .vcxproj file format at all. Only re-creating the .vcproj file from scratch is a sane approach.
If it is a .csproj or .vbproj file then you'll have a shot at it. The best way to go about it is to start a new project in VS2005 so the core entries in the file (Project, Import and PropertyGroup items) have a reasonable value. Then copy/paste the ItemGroups from the VS2013 project file. You'll get the correct reference assemblies and source files that way.
As Visual studio doesnt support for downgrade, you can't do it directly or by changing any file, I suggest better way to do is create another project in visual studio 2005 and import all files in it.
You can do this only if you didn't used any higher version libraries in your project than VS2005
Simple answer is that you can't (as far as I am aware). Fastest option would be to create a bank VS2005 solution and project to mimic your existing 2013 version. Then cut / paste the file listing between the two projects until it opens and builds in 2005. You also won't be able to use any functionality greater than .NET 2.0 and/or NuGet, which wasn't around / supported at that time.
VS2013 would have to convert a VS2005 solution / project just to open it, so there isn't really any hope of it going backwards (i.e. VS2005 being happy with a VS2013 solution/project file)
Visual studio project converter does the work for you. We are using it with success for VS2012 => VS2008 downgrades.
But if you have time, I would recommend you to inspect the code of this project and make a custom script in order to do the transformation. This way you can add it with no friction to your continous integration environment.
I am trying to convert a SharePoint 2010 solution (custom web parts, content types, lists, event receivers, etc.) developed in Visual Studio 2010 to SharePoint 2013 and Visual Studio 2012. When I open the project in VS 2012, it converts a couple of the project files but won't compile because of reference issues.
I copied the DLLs (mostly Microsoft.SharePoint..., although I needed to copy the Microsoft.Office.SecureStoreService.dll too) that were causing issues from my 2010 server to the 2013 server and fixed the references. However, the Microsoft.Office.SecureStoreService.dll still gives me compiler errors claiming "Error 203 The type or namespace name 'Office' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)" when visual studio has no problem with the namespace and finds the SecureStoreProvider class inside it just fine.
I've also tried to change the target framework from 3.5 to 4 and only see "Install other frameworks..." in the target framework dropdown.
I'm sure that others have dealt with this, but have been unsuccessful in framing the right google search query. I'm relatively new to SharePoint in general and any help would be appreciated.
thanks,
Mike
I was able to get my solution upgraded from a 2010 project to 2013 using the following. Note that this will update your solution to use the new 2013 API. It is possible to update just the project file but still run in 2010 mode.
First edit your .csproj file (for c#).
Modify the target framework to this:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
Add this a node for the office version, I put mine directly below the TargetFrameworkVersion tag
<TargetOfficeVersion>15.0</TargetOfficeVersion>
Update references
Reload the project and update your referenced assemblies. If you haven't specified a specific version they should already be referencing the v15 (SharePoint 2013) assemblies.
Do a find replace for 14.0.0.0 to 15.0.0.0. This updates any references on your pages, layouts, and master pages to the v15 assemblies.
Change calls
Change any calls to SPUtility.GetGenericSetupPath() to SPUtility.GetVersionedGenericSetupPath()
Check each file to do a check for any hive references. You'll need to add a /15/ to these. EG: _layouts/ to _layouts/15/
Open the package "folder" in visual studio then update the properties for that package to use version 15.
Clean up
Finally do a compile clean up any missed items. Deploy your solution and make sure to test thoroughly.
I am seeing a strange phenomenon in Visual Studio 2010.
My project setup is this (I inherited this - can't change it any time soon, unfortunately :-():
a Winforms app that uses Crystal Reports X (v10) as its reporting engine; full CR X Developer Edition is installed on my dev box
several Webforms apps that use Crystal Reports XI (v11) as their reporting engine - cannot install CR XI full version, since it clashes with CR X Dev Edition....
In order to make things work on our build server, I also created a Library folder inside the Winforms app's project directory with the CR X runtime files I need, as well as a Library folder inside the web app's project directory with the CR XI runtime files.
In VS 2008, I was able to pick the necessary assemblies from the respective library folder in my Winforms projects (several class libraries etc.), and in my web apps. Everything worked great.
When I updated to Visual Studio 2010, now suddenly I'm seeing:
in my Winforms apps, all the references to CR X runtime files are being automagically updated to use the CR X files from the GAC - this is not what I want! It doesn't help if I delete those references and re-add them again by browsing to the Library folder - when I pick them, VS2010 seems to automagically conver them to GAC references again...
in my Web apps, things get even worse: when I pick the CR XI runtime assemblies from the Library folder, again, VS2010 automagically seems to detect there are similar files (same name, but different versions) in the GAC and uses those files instead - now my web apps don't work anymore.....
What the h*** is going on with VS 2010 here?? Why can't it leave my selections alone and let me choose my runtime files from a Library folder instead of insisting on going to the GAC?? What has changed between VS 2008 and VS 2010 in this respect?? Does anyone have any insights into this??
It may be useful to either
(1) go to Tools\Options\Project&Solutions\Build&Run and change MSBuild verbosity to 'diagnostic' and then build and in the Output window see how the MSBuild reference resolution logic is working for those assemblies. That is, if VS hasn't already done something ridiculous to the underlying .csproj file
(2) compare the XML in the VS2008 project file versus the VS2010 project file to see what's in the <Reference> nodes
A wild speculative guess: the VS2010 project is targeting ".NET 4.0 Client" (rather than ".NET 4.0 (full framework)", and the libraries need the full framework, and MSBuild sees this dependency and is using fallback logic.
I have a Visual Studio 2008 solution which builds a C# class library (Project X) and C# Windows Application (Project Y).
In the unit test project for the C# class library (XTEST) , Intellisense works as expected and auto-completes the names of classes etc.
In the unit test project for the windows application (YTEST), Intellisense has stopped working and only auto-completes with the names of accessor classes, not the names of actual classes. Intellisense also reports lots of class names as being unknown/undefined. These appear in the error tab, but disappear after compilation.
Possibly relevant facts:
The projects all build correctly, and the tests run.
All programming is in C#, .Net 2.0 Framework, VS 2008 SP1.
It used to work...!
The Project Y was converted to VS 2010, then converted back to V20008 at one point. It's possible that other projects may have been converted and then converted back too.
Can any inspired reader point me in the right direction to fix the Intellisense in Project YTEST?
Answer
Turned out to be an issue with .cache files in the project obj directory. Deleting these fixed the problem.
For Visual Studio 2013, I couldn't find .ncb files in project folder. But deleting all the .cache files in obj\Debug folder worked. Didn't have to restart the VS.
Source: Grantly's comment.
try deleting the .ncb file in your project folder.
This will force intellisence to regenerate the symbol database.
what helped me was simply unloading and re-loading the project