I added the monogame files into the project templates folder in vs 2019, but it just gives me this error and I have no idea how to fix it:
Error I get
I've tried deleting and redownloading the monogame files multiple times and it works on the computers at school by doing the same thing that I did, but won't work on my home computer. When I tried to open a project on my home computer that I created on a school computer it corrupted it and I had to redo the project.
You need to download and install Monogame 3.7.
There was no "corruption" of the source files, only the project and .sln files.
Everything you wrote still exists in the source .cs files, simply copy the .cs files from your old project to the new one.
Related
(Apologies- I originally posted this under another case that had the same type of error message:
Microsoft.VisualBasic.Powerpacks.ShapeContainer not found)
My VS2019 project loads with 53 errors now, after reinstalling everything on a new HDD, after the Dec 2022 MS update killed my old Win 10 system.
Opening the project in VS2019 gives lots of errors like: 'Microsoft.VisualBasic.PowerPacks.ShapeContainer' is not defined
'Microsoft.VisualBasic.PowerPacks.Shape' is not defined
'Microsoft.VisualBasic.PowerPacks.OvalShape' is not defined
or 'FillGradientStyle' is not a member of 'PowerPacks'.
On the old win 10 system, all my projects worked fine. I migrated one of the projects from VS2008 to VS2019 and got it working in both versions.
Now in the new Win 10 install, I installed VS2008 again and VS2019 then copied my project folders over to my C drive.
My old Win 10 system and my old Win 7 system had a directory in Program Files x86 called 'Microsoft Visual Basic 2005 Power Packs', and inside is a folder named '3.0'; but I cannot find this anywhere (the download link provided in the other case does not exist now), so I simply copied that old directory over to my new Win 10 C:\Program Files (x86).
Opening the project in VS2019 gives lots of errors as shown above.
I also tried copying my old VS2008 version project folder over, and even opening that in VS2008 it gives these errors now.
The project references in both versions of the project already have C:\Program Files (x86)\Common Files\microsoft shared\Visual Basic Power Packs\1.1\Microsoft.VisualBasic.PowerPacks.Vs.dll and when I select this in the references window, the properties window populates and shows it is Version 9.0.0 (but RunTime Version v2.0.50727). The actual DLL file referenced shows File and Product version 9.0.30729 and says the Product Name is Microsoft (R) Visual Studio (R) 2008. So it seems like both the VS2008 and the VS2019 projects already were referencing the Powerpacks.Vs that was installed by VS2008 and they should work. (They worked in the old Win 10 system before MS ruined it).
The Visual Basic 2005 Power Packs folder was only copied, not installed (possible problem?) but that may be a red herring because the project has a reference to the VisualBasic.PowerPacks.Vs.dll.
What has happened? How do I fix it?
More Info: The Toolbox is empty, but maybe that's because it only populates once a form is open. The main form will not open because it has components from the Powerpacks, like oval shapes and containers, so I understand the toolbox not populating there. When I open my 'About' form, the toolbox populates, but the VisualBasicPowerpacks section has only a Pointer and PrintForm icon! No other shapes/components!
Just tried 'Choose Items' context menu option for the toolbox, but there are no Powerpack entries there, even though the project references include the Powerpacks .Vs.
OK, I have finally stumbled upon a solution myself. (Been working on this for a few days).
I believe there may be some incompatibility/confusion in how Visual Studio references powerpack versions.
Although my project had powerpacks.Vs referenced, and the Vs dll was there at the path, it clearly wasn't working.
Just now I opened the references window and clicked Add, then browsed to the C:\Program Files (x86)\Microsoft Visual Basic 2005 Power Packs\3.0 directory that I had copied from my old drive, selected the Microsoft.VisualBasic.PowerPacks.dll there (file version 3.0.30214.0) and clicked OK.
Now both powerpack dlls are listed.
Then I opened the main form -bingo- it loaded. The errors seemed to vanish.
I opened the toolbox and had to select the main form then another tab a few times before it loaded.
I right-clicked in the toolbox and added a new tab, named it Visual Basic Powerpacks 3.0 then right-clicked and selected 'Choose Items".
I found all the shapes (rectangle, oval, line) and selected them and clicked oK. They now are in the toolbox.
So I don't know why it didn't just work when I copied the project files over to my new install, but maybe when I opened the project it couldn't find the 3.0 and so changed the reference to the Vs version?
Maybe someone knows what actually happened. At least if anyone is caught by this problem this is quite likely what they need to do.I was lucky that I still have access to that old Powerpacks 3.0 directory, because it seems Microsoft has taken the old download page away.
Is it possible to import an already existing Umbraco site into Visual Studio? (By means of getting all the site files and DB backup)
I've tried creating an empty project and copying the website files, but I get several errors when I try to compile the solution. The errors look like "Could not find scheme information for the element 'umbracoConfiguration'."
The same happens if I create an empty solution, add the UMBRACO nuget package, and then copy the website files.
I'm wondering if it is at all possible, or if once an UMBRACO website is running, how should one customize/develop on it?
THANK YOU!
After several attempts and trial and error, as well as reading other blogs, the way it worked for me was to go in Visual Studio -> File -> Open -> Web Site... and select the main folder containing all the files.
It is important to know that the web.config had to be modified in advanced for the website to work to point to the local server and off course attach the DB to the local SQL server.
Everything works perfectly just the way it was working on the host, and I have the solution in Visual Studio.
I like to start with nuget because it handles setting up all of my project references. I create a new MVC4 Web Application
Visual Studio->File->New->Project->MVC4 Web Application
After I create the new application, I open the Nuget Package Manager Console
Tools->NuGet Package Manager->Package Manager Console
I then enter the command:
Install-Package UmbracoCms.Core -Version 7.2.1
I find that installing the UmbracoCms.Core instead of the whole UmbracoCms nuget package is best because it only sets me up with the umbraco dlls and sets up the references for me. The UmbracoCms nuget package tries to do a lot more and is more handy if you are setting up a brand new umbraco site in Visual Studio.
Once I have nugetted the appropriate version of umbraco, I copy my existing umbraco site files over the files that were nugetted. When you copy all of the files over, don't copy all of the App_Data. Most of the files in that directory are TEMP files and cache files. From App_Data, only copy the following. This will save you time reindexing the site. I suspect a lot of the App_Data files were responsible for your Object Null Reference.
App_Data/access.config
App_Data/packages/*
In visual studio, in the solution explorer, click "Show All Files", and then include the appropriate files in the solution. Rebuild the solution, and you should be set up for development.
I'm working on a project in Visual studios 2013. I was trying to figure out how to do something and was recommended to look at another project on TFS that does something similar. When I got latest version of this other project, I found out it was made in VS2010. It migrated it to VS2013, and locked the file to me. I undid the changes because I don't want to modify this other program. I was unable to find a way to open that file without it trying to lock the file to me with migrating to VS2013.
As an attempted solution, I copied the file elsewhere on my computer and tried opening it without connecting to TFS. I assumed this would allow it to migrate to 2013 without updating the database. It still had issues and gave me this error: Solution file '%s' cannot be migrated because the solution cannot be checked out from source code control. To migrate the solution, make sure the solution file can be checked out and re-open it.
How can I open this solution without updating the TFS solution and locking the file to myself?
I just ran into this same problem. I checked the permissions on the solution files I was trying to open and saw that it was set to 'read-only'. I deselected read-only and the solution opened.
If everyone else is using VS2010 with Service Pack 1, then upgrading the solution isn't a problem. People will still be able to open it in VS2010 SP1, even if you check it in. See the Visual Studio 2013 Compatibility notes on MSDN for specific things to watch for.
Alternatively, after checking the files out but before opening the .sln file, create a copy of it in the same folder calling it MyProject2013.sln (for example). Add this new solution to source control using Source Control Explorer and then open it, letting Visual Studio upgrade the .sln file as it would normally. The 2010 .sln file will be left untouched and you should be OK to do what you like with the 2013 solution.
If I try to open one of my projects in VS2010 on our build machine I get the error: "The project type is not supported by this installation". This is because I don't have MVC 4 installed on this machine. As I would like to keep my build machine as clean as possible I would like NOT to install MVC 4 (and deploy/reference the needed DLLs manually). Is it safe to edit my project file and to remove {E3E379DF-F4C6-4180-9B81-6769533ABE47} (MVC4) from <ProjectTypeGuids>?
You would be editing you solution file, not the project file in this case.
Well, if it's only you working on this, or you don't check the .sln back into source code once you have removed it, then yes.
If you do, it will be missing for others, who have MVC installed.
Alternatively, leave it in there as unloaded.
Another workaround would be to create a separate SLN file with everything but the offending project in.
EDIT
You would need MVC installed to be able to open / edit / do anything with this project.
I've been working on a web application (ASP.NET 4.5 Web Forms), and then added it to TFS to make the source code accessible to the client. I had no trouble getting it added to TFS, but when I got latest on a different machine (than the one I developed on) to test if TFS was working, I'm running into a bunch of reference errors to basic things like EntityFramework, Microsoft.ScriptManager, System.Web.Optimization. A client has run into the same issue when he checked out.
The thing is, if I create a new web application project on this machine, it has all those same references, but they're working correctly.
I've seen suggestions to add the actual DLLs to the project in a /lib folder, then reference them instead, but I don't think that's the right course of action for these basic, built-in assemblies.
One more thing- when I publish to Azure, it works just fine.
Any clue how I can get these references working properly?
Full list of broken references:
- AspNet.ScriptManager.jQuery
- AspNet.ScriptManager.jQuery.IO.Combined
- EntityFramework
- Microsoft.AspNet.Membership.OpenAuth
- Microsoft.Aspnet.Web.Optimization.WebForms
- Microsofot.ScriptManager.MSAjax
- Microsoft.ScriptManager.WebForms
- System.Web.Optimization
EDIT: I finally got this figured out. Apparently even these key assemblies are generated into the "packages" folder where the project is located. I added this folder to source control and it worked fine.
Right click on one of the references (on your machine) select properties, then check the full path to where the assemblies are located.
If they are in a folder called packages under your solution then they are NuGet packages not built in assemblies. Which means you either need to check the packages folder into source control, or right click the solution and enable package restore mode.
If they are program files then they aren't really built in assemblies either, they're likely installed by something else you installed onto that machine.