I have been unable to revert a winforms project from .net 4 back to .net 3.5 due to bugs in visual studio 2010. The program manager says in a forum it was not a design goal to permit round trip development to previous versions (!). The error is in the resx files:
error RG0000: Object reference not set to an instance of an object.
http://connect.microsoft.com/VisualStudio/feedback/details/557469/visual-studio-2010-generates-invalid-assembly-in-some-cases
"This is the intended way in which the product was designed. And, we do not support round-tripping with previous versions of the product. As such, I am resolving the issue, "By Design"."
I tried manually editing a resx file back to 3.5 and couldn't do it. Any suggestions for this appreciated.
Assuming you haven't got a previous version for what ever reason, the simplest solution would be to delete the .resx files and recreate them in the 3.5 version of the project. Take a copy of the project so you can open the offending .resx files and copy the resources to the clipboard. Pasting them back into the 3.5 version should just paste the content.
Get the last working version just before you did the upgrade from source control. You do use source control right?
Related
I like the new .csproj format introduced in 2017 but I'm disappointed that no .NET framework project templates got any new .csproj templates (Yes, XNA doesn't have one for obvious reasons).
I've already managed to take a base .NET Standard library and turn it into a .NET Framework executable using the new format, but this doesn't seem to work for any projects that rely on the <ProjectTypeGuids> tag for special functionality. WPF xaml files refuse to use the designer and the add new Window ability isn't present anywhere (Strangely enough, UserControl is present).
XNA is more understandable why it doesn't work, but my first and main roadblock I'm encountering is that the old method for including XNA dlls doesn't work (Get the warning icon) and new methods are just as fruitless. I can't seem to find how to add extra reference paths to new .csproj formats like in the old format.
Anyways, is this even possible to do at the moment in Visual Studio 2017, or are these specialized project types consigned to the old .csproj format for now?
Old project types like WPF, Winforms don't support the new csproj format via Microsoft SDK at the moment.
There are some hacks, additional SDKs which try to solve it.
So currently you should stay at old format.
I am creating a Coded UI test for our system which runs on Sharepoint 2010. Part of the test sequence is creating a site; Sharepoint's UI for creating sites runs on Silverlight. Therefore, I need to create a Coded UI test for a Silverlight component which is part of out-of-the-box Sharepoint rather then part of our application. When I try to record a test, I get the following message:
No Silverlight controls where detected. Verify that the application under test is built using Silverlight assemblies with a version of 4.0 or greater and that a reference to the Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll assembly has been added to the project. For more information, see http://go.microsoft.com/fwlink/?LinkId=204562
I have two questions:
1) How can I find out the Silverlight version which Sharepoint components are built against? If they are built against Silverlight version 3.5 or earlier - I suppose the problem is unresolvable?
2) Assuming the previous question is answered - how can I make Sharepoint's Silverlight components reference the SilverlightUIAutomationHelper.dll library? That seems problematic at best to me...
Silverlight version installed on the test machine is 4; Visual Studio Feature Pack 2 is installed.
Thanks.
You can't make SharePoint's Silverlight components reference the automation helper library unless you have the source code and can recompile them. So the answer to your first question doesn't really matter.
You could modify Sharepoint XAPs to simply add Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll in there. You don't really need the code itself to reference it, it just has to part of the package. The XAP file is just a zip file so you should be able to modify this.
You will have to find where Sharepoint is getting the XAPs from and change the source (obviously you don't want to do this in prod boxes and there's even a license restriction for the Automation dll that prevents you from do it). You could also write a Fiddler AutoResponder to modify the XAP file and add the dll before it gets to the browser. For an example of this have a look at this AutoResponder:
https://bitbucket.org/mamadero/hackingsilverlightdemo/src/2fecb7b59dec/FiddlerAutoResponder
I created a new Silverlight Navigation Application using Visual Studio 2010. I didn't make any changes to the code. Just Pressed F5 to run. I get the following error message:
The type 'System.Windows.Navigation.NavigationEventArgs' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.Controls.Navigation.dll' and 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.dll'
I right clicked the Silverlight Navigation Application folder in the solution explorer and changed its "Target Silverlight Version" from Silverlight 4 to Silverlight 3 and then ran the application (by pressing F5) and it works fine.
I've already spent a lot of time trying to fine a solution. I want to develop application using Silverlight 4.
Would really appreciate any help with this.
Regards,
Vivek
It sounds like you have Silverlight 4's runtime, but an older set of VS tools or an older SDK, or your project is somehow referencing the older SDK.
Basically, that type moved from the System.Windows.Controls.Navigation DLL (where it was in SL3) to System.Windows.dll (where it is in SL4). CLR type-forwarding should take care of this.
Since Silverlight version numbers on assemblies didn't change between SL3 and SL4 it can be somewhat hard to tell if you're in the situation where you have outdated tools/SDK. Check the last modified date on System.Windows.Controls.Navigation.dll and see if it looks like about the time SL4 was released, or check if the Frame control has a property called ContentLoader - if so, you have the updated bits (and my answer is thus not helping). If not, however, then try reinstalling the SL4 Tools and/or SDK and check that your project is referencing the v4 Navigation assembly.
Just downloaded the Silverlight 3 Toolkit and executed the MSI file.
Now I need to reference the Microsoft.Windows.Controls.dll file but don't know where MSI unpacked it. Can't find it at C:\ or in C:\Program Files. Where might it be?
ok, this post says that all the components should be in the toolbox, e.g. DockPanel, they are for Visual Studio 2008 Professional but not for Visual Web Developer 2008 Express (it has some controls but not DockPanel for instance)
Answer:
Ok, the answer is: reboot and restart everything (until then Silverlight got a AG_E_PARSER_BAD_TYPE error, and brought down both Visual Studio versions and Firefox). After restarting everything, it works fine: the controls are automatically in the toolbox so you just have to drag them in, no need referencing the dll anymore as in Silverlight 2.
It didnt automatically add anything for me for Silverlight Beta 4 Toolkit and Visual Studio 2010 Beta 2.
I followed these instructions. My toolkit bin was located :
C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Toolkit
In addition I had to select additional DLLs for additional toolkit items from those described in the article. I also had to check the checkbox to indicate I actually wanted those items.
There must be a better way! Anyone?
Just in case anyone was wondering, I was :-).
There is a start menu group named "Microsoft Silverlight 3 Toolkit March 2009" with all the relevant info. The toolkit assemblies can be found in "C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Toolkit\March 2009\Libraries"
The July 2009 release of the Silverlight Toolkit added a "Open the welcome page" choice at the end of the MSI setup.
The path names for the July release are also slightly different, but using the Welcome page (a link is also added to the Start Menu), you'll always have a quick method to find 'em.
Checking that box will make sure that a page opens up with details about everything that's installed, including links to all the binaries, themes, the documentation, etc.
Also, since the controls are all referenced through the AssemblyFolderEx registry key, you can add a GAC-style reference in your C# or VB.NET project...
<Reference Include="System.Windows.Controls.Input.Toolkit" />
And that will just work when built on a machine with the Silverlight SDK.
Hopefully it's a step in the right direction.
We are using Visual Studio 2008 to develop a winforms application stored in Visual Source Safe 2005.
If one of our team members changes a *.Designer.cs file without changing the form's source file the change doesn't appear during a "Get" operation. However, if in Visual Studio you run a compare on the *.Designer.cs file the differences are displayed in the difference viewer.
FYI: We are using the default Microsoft Visual SourceSafe plug in for Visual Studio.
Any ideas why the "Get" operation will not detect changes in the *.Designer.cs files and suggest we pull down the latest version?
Thanks for your help!
Designer files are not intended for manual manipulation. One of the chief incentives for adding partial classes to the popular .Net languages was to segregate the designer-generated code from manual user code, in fact. Manual manipulation of repeatedly-generated code (in pretty much any environment, not just visual studio) is asking for headaches.
What changes are you making to the designer file, and why is it not possible to make those changes to the non-designer source file?
Edit:
Is the project in the IDE properly bound and connected to the source control database (via File->Source Control->Change Source Control)? It should automatically be checking out the designer files when changes are made in the designer view.
I would try doing a Get manually through VSS Explorer (i.e. not through Visual Studio) and see if it works. If not, check to see if the file is pinned to a previous version.
Woe unto you for having to use SourceSafe. At my last job, we used SourceSafe and had a myriad of problems with it. We switched over to Surround SCM and were really happy with it. I'd never heard of it before that job.
To answer your question, any time I ran into a problem like this with SS, I'd do a "forced get": in the options dialog when you get latest, tell SourceSafe to get the latest version from the server regardless of whether it thinks the file is up to date.
Edit: I think the issue is the VS200X plugin for VSS. If you have the VSS standalone application you should be able to do a forced get from there. I now remember having to do this so often that I stopped using the VS200X plugin.