We have got a C# Windows application which uses devexpress controls, enterprise library and CC.net for building. We are planning to migrate VS2010 soon.
Have you come across similar situations? Are there any unforeseen issues?
If your code makes use of any of these features listed in column 1, you might need to take a look at this:
http://msdn.microsoft.com/en-us/library/ee855831.aspx
If you are still targeting .NET 3.5 then the move should be very smooth. We recently moved a very large WinForms app across and encountered a couple of minor issues:
Some of our resx files contained serialized generic lists of our own custom types, which caused compile errors. Never got to the bottom of why this was, but we just deleted them from the resx files and set the [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)] attribute on the offending properties
The syntax checking of XML comments is slightly stricter, meaning you could get extra warnings (and with all warnings as errors turned on this broke our build)
We did a similar migration almost a year ago (just after Visual Studio 2010 was released). That was a little bit too early as DevExpress were not quite ready with their .NET 4 version yet. We had to run the web application in "compatibility mode" for a week or so.
There were very few issues. From what I remember (our product is half .NET and half C++):
Some third party controls needed updating
Some internal names crashed with new .NET 4 BCL classes.
C++ project started to use MSBuild so that was some work up upgrade the project files.
I faced this : on XP machine, trying to build a project referencing a COM with multiple objects inside. Specifically, i've encountered this with INetFwMgr - (The type or namespace name 'INetFwMgr' could not be found (are you missing a using directive or an assembly reference?). Its seems that i am not the only one.
EDIT: solution here.
Related
I recently upgraded an old C# application to 4.6 framework so that I could consume a vital service that was moving to 4.6. After I did that my fckEditor had 102 compile errors. This did not make any sense because it had been working just fine for years. So, I upgraded to CfEditor and I still have 102 errors.
An example of one of the errors is:
'addedCount' is not declared. It may be inaccessible due to its protection level.
I have that type of error around 20 times.
All the errors are in the CFEditor code. Any advice on how to fix this?
Did you change the target framework version for the package? Try doing that and cleaning and rebuilding your solution. If you're using Visual Studio, this has caused me problems in the past after applying a dramatic change like updating framework version. Try restarting the editor as well.
I am assuming that this place you're having an issue with is resolved via a package manager. Please give more context if this isn't the case.
Thanks for replying. Last night, right before I stopped for the day. I removed the folder and the DLL and then added everything back in and Walla! Everything worked. It looked like the folder that I removed had stuff in it that didn't belong.
I keep running into an issue with our TFS build server. I've got 2 projects (both in the same solution), 1 is a WebForms project, running .Net 4.0. The second is an ASP .Net MVC5 project running .Net 4.5. There is also a Silverlight project, but the problem is reproducible with just the first two.
Both of these projects use NuGet packages for various libraries. Sometimes there are different assemblies within a package for their respective environments. A .Net 4.0, 4.5, SL assembly, etc.
The build server seems to dump all of the libraries required into a single folder, then pulls from that to build the solution. This causes problems in many cases, with the wrong project getting the wrong assembly version. This does not occur locally, only on the build server. I can't figure out what I need to do to keep this from happening. Any ideas?
Yes, I hate this standard behavior, but TFS will output everything to the same folder by default, and then you will get various errors depending on which order msbuild compiles your projects if you have references with the same name or even project outputs with the same name.
The easiest workaround is to use the AsConfigured option on the Process tab, '2. Build' -> 'Output location' of the build definition window. This keeps your normal source structure intact, but I think you will lose support for automatically dropped outputs (i.e. you will have to provide a script to do that yourself). If you are only using TFS Build for validation, this is the cleanest approach.
You can also use the PerProject setting and split up your projects into two distinct solutions, perhaps suffixed by platform (we've done that numerous times in our company). Then, you specify both solutions to the build process and it will create two separate folders in the output, one for each solution.
This is all assuming you are using TFS 2013. In TFS2012, there is a similar option but it is in '3. Advanced' -> 'Solution Specific Build Outputs'. You will probably have to go this route if you are using TFS2012 or you will need to modify the default workflow yourself to add your own logic.
EDIT:
From your comment to the other poster I see you are using TFS 2010. Well... I think this was absolutely not supported at that time, I remember having similar problems, but we upgraded to TFS 2012 and all was well.
I think your only option is to either create two separate build definitions and build each solution that way, or you will need to checkout the xaml workflow and edit it with your own logic. Perhaps downloading the TFS2012 template and "porting" it to TFS2010 would be a better approach since at least you would not be reinventing the wheel that way.
ide: vs 2012 v11.0.60610.01 update 3
project: web site, mix of vb and c#
problem: vb navigates to definition, c# navigates to metadata
complaint: complete pain in the ass when managing a 30k code-line project.
solution: you be the first to figure this out, it's beyond my level of patience.
i find metadata to be 110% useless.
is there ANY way to get c# to navigate to the actual definition like vb does?
thanks
If it's navigating to the metadata, rather than the definition, it probably has to do with how your assemblies were added. If you add a reference as a DLL, it will always show metadata, even if that project is included in your solution; you have to add a reference by project to have access to the source.
"i find metadata to be 110% useless. is there ANY way to get c# to navigate to the actual definition like vb does?"
Resharper's go to definition/go to implementation options work exactly as you'd expect - worth trying it to see if it fixes your issue.
This question might be of help if you choose not to try resharper
I realize this is an old thread, but it seemed to be one of the few that focused on the role of mixed languages (C# and VB.NET) as a contributing factor to this.
I ran a few tests across VS.NET 2010, 2012, 2013, and 2015. My empirical results (not validated by any official Microsoft documentation) is that all 4 support Find All References of VB.NET members consumed by C# (albeit, split into apparently separate result groups), as long as project references were added. However, VS.NET 2010, 2012 and 2013 end up in the "from metadata" view for Go To Definition from the C# code to a VB.NET member. Where as VS.NET 2015 appears to have this cross-language Go To Definition navigation working correctly.
I also confirmed that using Resharper's support for External Sources does allow Go To Definition to work under VS.NET 2012, and that almost motivated me to purchase licenses for Resharper for our current project that has mixed C# and VB.NET projects, but now my plan is just to expedite adopting VS.NET 2015.
I'm working on a web app using VS 2008, .Net 3.5 and C#. Most of the projects in the solution are either classic asp.net pages with some MVC 1 in the mix, the rest is shared libraries. The solution is one that is some 5 years old and has gone through a variety of developers working on it and clearly has some performance and architectural issues.
Previously, I've been working on the project using VS 2008 on a Win XP machine, but have just transitioned over to a new box using Win 7 Ultimate. To do so, I've installed VS 2008, asp.net 3.5. To support future work on the solution I've also installed VS 2010 and asp.net 4.0.
Opening the solution on the new box with VS 2008 works fine, and it builds without error. However, when I attempt to run it with the debugger, I get the following message:
"There is an error in web.config. Please correct before proceeding. (You might rename the current web.config and add a new one.)"
I think it's clear that there is some sort of environmental issue regarding web.config on the new machine, but the error message is not "helpful". Adding a new web.config is not an option as the existing one is quite long and involved (too much to post here).
I'm hoping someone has a suggestion or two about where I might look for missing elements or changed configurations that might produce such an error message. Lacking that, I'll revisit this post and provide the web.config in the hope that will elicit further help.
So I don't know if you ever found an answer to this, but I ran into it in VS2013 today. Oddly, it would work if I had the web.config open in an editor window.
For others who may see this error I was able to clear it in VS2013 by deleting the \bin and \obj directories.
After that, it worked fine again...
To maybe give you a better idea of what the web.config problem is, I would follow the suggestion of renaming the current one and adding a new one. You can use a diff tool (e.g. WinMerge) to find out what the differences are between your existing config file and the "clean-slate" new one.
You can copy the non-issue sections from the old one to the new one, like the connection strings and the application settings, forms authentication modes, etc. You might have something wrong with the compiler section or something a little more specific to the .NET framework.
Did you convert the project at all from targeting .NET 2.0 to .NET 3.5? There's a big web.config section that gets added to 3.5 projects that wasn't required for 2.0 projects regarding the compiler, as it uses a separate compiler for .aspx inline-code than was used for 2.0.
iis 7.5 (on windows 7) is a pretty different animal than iis 6 (on windows xp). there are some configuration incompatibilities. one thing that comes to mind is a little different schema for the attributes on the elements for http handlers and modules. there are other things that are different. usually on the error page, it will tell you what it doesn't like. i imagine it was there and maybe you didn't notice it. or maybe you were hitting the page remotely and it didn't have all the detail. i suggest using a browser on the local machine and take a closer look - pretty sure it will tell you what is making it puke.
I ran into this ambiguous error for the first time today in VS2019. I had added a new Entity Model (.edmx) which required adding a new connection string to a separate project's web.config. After adding it, I immediately started getting the error on startup. I noticed there were several config transforms for the various environments. After adding the missing transformed connection strings to each of them that error has gone away.
My C# WinForms solution has two projects.
A DLL which is the main project I'm working on, and an executable WinForms I call "Sandbox" so that I can compile/run/debug the DLL easily in one go.
I'm working in .Net 4.0 for both projects.
Everything was working fine until I added some seemingly innocent code, and a reference to System.Web in the DLL.
Now my Sandbox project can't see the namespace of the DLL project. I didn't change anything which I believe should have affected this.
If I delete the project reference to the DLL from the Sandbox references and re-add it, then the red underlines all disappear and the colour coding comes back for all my classes etc; but as as soon as I try to build the solution, the whole thing falls apart again.
When I right-click the DLL project in the Sandbox's references and view in object browser, I can see the namespace and all the stuff in there.
I have a feeling this might be some sort of bug?
Is this some sort of VS2010 bug? I had this same issue a few months ago and I could only fix it at the time by making a whole new project and re-importing my files. This time, however, I have a bajillion files and will only do that as a last resort!
Edit:
After panickedly going through and undoing all my changes, trying to find what caused the problems, it seems to be this line:
string url = "http://maps.google.com?q=" + HttpUtility.UrlEncode(address);
If I comment out this line, then I get no namespace errors and the project builds fine. I can't see anything wrong with this line though.
I'm ready to declare this a bug in VS2010, this has bitten way too many programmers already. The fix is easy: Project + Properties, Application tab, change Target Framework to ".NET Framework 4" instead of the Client Profile that is selected by default.
System.Web is not included in the client profile. Having this option in the first place is quite silly, the client profile is only 15% smaller than the full version of .NET 4.0. Having it selected by default is even sillier. But I digress.
UPDATE: mercifully this all got fixed in VS2012. Which no longer makes the client profile the default for a new project. And the client profile got retired completely in .NET 4.5, good riddance.
Check to make sure that both projects are using the non-client profile for their target framework (go to each project's properties to do this).
One possibility is that the target .NET Framework version of the class library is higher than that of the project.
I faced this problem, and I solved it by closing visual studio, reopening visual studio, cleaning and rebuilding the solution. This worked for me. On some other posts, I have read the replies and most of users solved the problem by following this way.
Try building only the project with the Sandbox dll first independently.
Then point your executable project to the required dll and ensure copy local is set to true. in reference settings.
Tthen build the executable project.
Changing the target framework from the ".NET Framweork 4 Client Profile" to ".NET Framework 4" worked for me with a similar problem. I agree that the client profile doesn't seem to have much of an advantage to using it. I seem to get nailed with weird errors that I hunt for until I remember that Visual Studio defaults to the client profile. I guess the moral of the story when getting an error is: if "Rebuild Solution" doesn't work, check the Target framework...
If you tried already doing the Framework change, and still not worked, I hope this works for you (as it did for me): Simply add the necessary references from within your projects. Very obvious but I was doing it wrong until I found what was the issue.
I just had this issue and it turned out to be I had multiple namespaces being used that had the same object name (i.e. business objects had the same names as mvc models);
Fully qualifying the names fixed the issue for me.