I've recently installed VS2010 and I'm trying to upgrade a project that I created using VS2008 and WSSF (Web Service Software Factory). I've installed the 2010 version of WSSF and it's prerequisites. After upgrading, when I try to load the solution I get "blah.ssfproduct cannot be opened because its project type (.ssfproduct) is not supported by this version of the application". Absolutely no idea what to do :(
Cheers
Mark
The Service Factory for VS2008 has a custom project that holds the model files and the VS migration wizard doesn't know what to do with it. Fortunately, the 2010 version has changed this custom project to a normal C# class library project and all the model files can be added to it ('Add Existing") without modification. For the final release, we will include the few migration steps to keep everyone out of the woods. Sorry for not supplying it with our pre-release drops.
In case you haven't seen it, your question was also answered by a community member on the Service Factory community at http://servicefactory.codeplex.com/Thread/View.aspx?ThreadId=211726. The response includes steps that worked for one person and they seem solid to me too.
Cheers,
Don
Related
I work with Xamarin.Forms in Visual Studio since a few years, and updated my IDE recently (VS v. 16.3.7). Now I realized something is missing: the Shared Project option.
When i go through the Wizard to create a new project the question if I want to use Shared Project or PCL(or NetStandard) is now missing (see screenshot below from VS 2017)
I do know that you can still create a Shared Project and add an iOS and an Android project manually, but this is just too cumbersome. My question really is: Is there a reason why Microsoft went on to push the PCL/NetStandard above the Shared Project strategy?
I am specially confused about this decision since already back in 2016 #miguel.de.icaza declared his favorite option (for most cases) was the Shared Project strategy:
https://tirania.org/blog/archive/2016/Jan-22.html
For me, the PCL is just too cumbersome for most uses. It is like using a canon to kill a fly. It imposes too many limitations (limited API surface), forces you to jump through hoops to achieve some very basic tasks.
I have installed VS 2017 15.9.14, on this version, Portable Class Libraries (PCLs) are deprecated. You could use .NET Standard instead. On VS 2019, the default is .NET Standard.
On Microsoft document, MS recommend .NET Standard 2.0 libraries over Portable Class Libraries.
For more, please refer to the MS docs. https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing
My question really is: Is there a reason why Microsoft went on to push the PCL above the Shared Project strategy?
For MS announcement, PCL is deprecated, you could not find that when you create the project.
You could create the Shared project by File > New > Project > Shared Project template.
For more details, you could check the link below. https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/shared-projects?tabs=windows
Updated:
Is there a reason why Microsoft went on to push the >NetStandard< above the Shared Project strategy?".
For the old version of VS 2017, .Net Standard is an option of Shared Project strategy.For the latest version of VS, MS use .Net Standard as the default for Sharing Strategy.
Is there any doc where MS states why Shared Project is now deprecated/not available in the Xamarin.Forms project wizard?
PCL is deprecated. Shared Project is still in use, in my answer, I provide the second link about how to create the shared project.
Summarizing and adding to the answer by #WendyZang-MSFT:
I started a project using the Shared Project strategy around 4 years ago, and until now i have not found any issue/problem specific to it that would make me consider moving to .Net Standard.
Recently i went into the trouble of localization, and even that was possible using Shared Project without much hassle.
As mentioned above, after i saw that the latest version of Visual Studio 2019 was not offering the possibility of creating a Xamarin.Forms App as a Shared Project i got a bit worried thinking that i should migrate my solution. But the time hast passed by, and i just realized that MS encourages the use of .Net Standard, but Shared Project remains also a valid approach.
I have a Visual Studio 2010 project which I am converting to Visual Studio 2015.
I have two questions:
The project is currently using AjaxControlToolKit 4.1.60501.0. Should I upgrade it to latest version AjaxControlToolkit 17.1.1? Would there be any coding changes?
I created a sample project and installed AjaxControlToolkit 17.1.1 from Nuget package. I see it in references and also all the Ajax controls in toolbox. However, I do not see ToolKitScriptManager. I also tried to install using exe from DevExpress etc. but still don't find ToolKitScriptManager.
Please guide how to get it.
It really depends on your needs and your project structure.
We have upgrade guide for old versions: https://github.com/DevExpress/AjaxControlToolkit/wiki/Upgrading-from-v7.x-and-below
You can get to know from there, that ToolkitScriptManager is removed, so you need to replace it with standard ASP.NET ScriptManager.
If you use AjaxFileUpload in your project, it's strongly advised to upgrade it to the latest version, because v17.1.1 contains major security fixes.
As a general rule, we advise you to use the latest version of the toolkit, because we can not deliver bug fixes and improvements to the old versions.
I created a new MVC project in Visual Studio 2017. I wanted to add an EDMX file (I will be doing database-first) so right clicked on the project and selected Add|New Item.
However, I cannot find the Entity Framework components that were available in the previous versions of Visual Studio. Does anyone know where they went?
I had a similar issue today after i updated my VS to the latest 2017 version. I tried to open an .edmx file in VS2017 and it didn't show the designer view. So i realised i forgot to select Entity Framework tools during the installation:
Everything is back to normal :)
In .NET Framework-based projects, the Entity Framework 6 templates are still there. However, for .NET Core-based projects, I believe you're expected to use the dotnet ef commands. This includes a means of scaffolding a code-first DbContext from an existing database. See ASP.NET Core - Existing Database.
To verify this, I setup a demo project with the following structure:
The New Item/Data dialog for the .NET Framework project:
Note that there is also an EF POCO Generator template available in the Online templates section that may be of interest to you:
I know this is late, but I ran into the same exact issue. After reading some of the other answers, I realized I had created a .Net project with Standard library instead of the Framework library.
I faced this issue, while creating an MVC application on my latest installation of VS2017.
Failed:
Tried installing Entity Framework using Nuget package manager[Install-Package EntityFramework], but failed to show Ado.NET Entity data model
Success:
1. open programs under control panel and select Visual Studio 2017
2. select Change the installation
3. Select Modify installation
4. Select Individual components
5. If SQL server data tools already installed, deselect/uninstall this component and reinstall the same again.
6. uninstall and reinstall SQL Server Data tools
Note: with one component change, other components may also be deleted. You have to recheck while reinstalling
I have a number of extension methods on System.Web.Mvc.HtmlHelper. They all work, the pages load up just fine. No compilation errors nor runtime errors. I am using my own derived view class, derived from System.Web.Mvc.WebViewPage< T >
The issue is intellisense in these views are not showing my extension methods as available. In fact they're not showing anything as available from my derived view class. When I go to definition on the #Html it shows that VS is looking at System.Web.WebPages.HtmlHelper.
Is there a way to correct this and have Visual Studio recognize the base class I'm using? Once again this all builds correctly and runs just fine, everything works as expected.
Additional info while researching this:
It looks like tooling support for VS 2012 and MVC 5 has yet to be released and is currently expected to be released in mid-november. Source. This may indicate the support isn't complete in VS2013 as well.
When you upgrade to MVC5 through Nuget, there are a number of files that need to be edited in order to ensure that your application builds and runs correctly, and has support for the right tooling.
All of this information is captured in this Microsoft guide for upgrading from ASP.NET MVC 4 to ASP.NET MVC 5. Please note that if you read the comments of the guide, there is still an issue with VS2012's tooling due to what VS2012 expects versus the updates to the way the new toolchain attempts to find binaries. A patch is expected for MVC5 support in VS2012 by November 2013.
Hopefully following the steps in the guide help you solve your issue. They worked fine for me. (Note that I started from a base project and attempted to upgrade it in VS2013. I did not start with an existing project.)
I have installed VS 2010 and want to migrate all code written in VS 2005 to VS 2010.
Please note that we do not have VS 2008, all code are in C# 2.0 and Asp.net 2.0 only.
Can anyone please tell me now what all points need to be considered while migrating.
Update:
I have set target framework to 2.0 for all of my Libraries and web projects. It complies without any error!
However, when site opens in IE (Set to default.aspx), it gives me error as below:
InternalXmlHelper.vb(9) : error BC30560: 'ExtensionAttribute' is
ambiguous in the namespace 'System.Runtime.CompilerServices'.
<Global.System.Runtime.CompilerServices.ExtensionAttribute()> _
Keep all the target framework settings to .NET 2.0. This way, there should be no compilation problem at all.
The changes that you should see are the solution and project files only.
Start with known good solutions in source control (and label—you shouldn't need to go back, but easy to add an extra safety net).
Open each solution in VS2010, allow the conversion wizard to do the conversion.
Resolve any issues.
Honestly, if you're just upgrading VS 2010 you don't really need to consider much. Just keep backups (any real SCM product will do) and you're good. You don't have to upgrade your applications' runtime targets at all if you don't want to.
If you're building with CAS policy, you might run into issues with using MSBuild 4.0 to build you 2.0 applications. If you don't know what I'm talking about, never mind.
My advice is to make sure everyone's "checked in" to your source code provider, and run the conversion wizard and see how it goes.