Visual Studio Crash on creating new Class - nanoframework

Visual Studio 2019 16.6.5 frequently crashes when creating a new class/interface or renaming an existing class/interface. This seems to be related to the nanoframework extension as it never happens when I am developing Windows applications.
Andy

I've seen this on projects under Git version control. The nanoFramework extension is not called during the rename process which is exclusively handled by VS. So it's unlikely that this is related with our extension.

Related

What must be done to make net5.0 usable in Visual Studio Community Mac 2019 for VB.NET console projects?

I want to write a cross-platform console application in VB.NET using Visual Studio Community Mac 2019 [VSCM2019]. It has to be able to be run on all platforms that dotnet 5.x currently supports.
When I create a new VB.NET console application in VSCM2019 it defaults to NET Frameworks 4.8 or lower. When I try to change that to net5.x in the project properties, net5.x is not offered in the dropdown list despite the fact that I have installed the latest dotnet 5 sdk.
Is it the case that I must select net5.x when creating the project? If so, where is this done for VB.NET console applications?
Whether or not VB.NET is supported or not, I managed to hack it into submission. I created a net5 C# project, renamed the .csproj file to .vbproj and replaced the .cs file with a .vb file. Instead of opening VS via the .sln file, I opened it via the .vbproj file. It compiled and ran and the project properties reflected the change to VB.NET. I then replaced the .sln by saving the project.

Where is the TFS build process going?

Im having a hard time figuring out what the best approach is when designing my build process. It seems Microsoft have turned things around (again).
I am using TFS 2015 and Visual Studio 2015. For earlier versions of TFS I have normally created custom code activities that I plug in to my build definition process file (xaml). I like this approach because it gives me great flexibility and enables me to code .NET classes. I used these guides:
https://msdn.microsoft.com/en-us/library/dd647551(v=vs.120).aspx
http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx
In TFS 2015 it seems that there is no documentation on how to create custom code activities. In fact, it seems that Microsoft have changed things and now focuses on scripting languages in stead of custom .NET code: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/steps/index.
I have created a custom code activity and it seems to be working in TFS 2015 (with a few hacks) so it is still possible, but I am nervous that this approach is no longer the way to go.
Can anyone provide information about what is happening here?
TFS 2015 introduces new builds, which are web- and script-based, and highly customizable. Meanwhile, TFS 2015 will continue to support the XAML Build templates and controllers.
The new builds are based on a different architecture and run on a completely different system. Currently, you can use both the new builds and agents alongside your XAML builds, controllers, and agents.
Which builds should I use?
If you are new to Team Foundation Server (TFS) and Visual Studio Team Services, you should use this new system. Most customers with experience using TFS and XAML builds will also get better outcomes by using the new system.
The new builds are web- and script-based, and highly customizable. They leave behind many of the problems and limitations of the XAML builds. For example, this new system embraces the diverse set of domain-specific languages (DSLs) that developers used to build the code on their dev machines. We expect this will reduce the chances of running into the "builds fine on my machine but not on the CI server" problem.
If you have heavily customized XAML builds and custom activities, you can continue using those builds until you are ready to port your business logic into scripts that can run in the new builds.
Useful articles for your reference:
https://blogs.msdn.microsoft.com/visualstudioalm/2015/02/12/build-futures/
https://msdn.microsoft.com/en-us/library/vs/alm/build/feature-overview

Deploying an application on a non-dev machine, having issue with a dll

I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.

Visual Studio won't find references

I'm working with some application handed over by another person in which I must document the requirements, build and deploy processes.
The problem here is that Visual Studio (2005) is throwing a lot of errors since it can't find the references for the dlls.
This obviously won't let VS build the project.
Everything works fine on the persons computer but not on mine, even though the project references the same folder where the dlls are, the bin folder.
How can I circumvent these problems and get VS to properly reference the dlls?
The following printscreen shows the references screen for the project.
My guess is that your DLL uses a more recent .NET framework than your application does.
Check the properties for your DLL source (right-click on the DLL code in the solution explorer and choose Properties). Go to Application - Target .NET framework and compare the version to the one the application itself uses (right-click on the project code). Note: under your application properties check both the settings under Application - Target .NET framework AND under Publish - Prerequisites.
For what it's worth, even after changing the .vbproj file and removing many lines about hard coded values,
I eventually checked out the project again removed all references to the given DLL and then added it using the GUI.
Lesson learned, don't try to change out one DLL for a newer version without using VB2005 GUI.
The easiest solution will probably be to transfer everything to another project. It will be incredibly time consuming to find where visual studio has left the hard coded path at.
WOOT!!!! Compile the DLL file to a lower version of the .NET framework, and it will fix the problem!!!!
The paths in the project file cannot be the same or the assemblies referenced have a different version.
It might be worth unloading your project and the editing it to inspect where it's looking and for what version.
I had the same problem with an older Visual Studio Project that I opened in Visual Studio 2008. I tried to add new references to the project and got permanent errors that the dll's cannot be found. After the migration of the Project to Visual Studio 2010 I got the following error message when I tried to add a new reference:
'mySample.dll' or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project. You can change ...
After changing the projects .NET Framework to a newer version everything works fine.
Good suggestions in other answers. In my case, it was because the libraries weren't copied (downloaded) successfully: the files existed, but were 0 kB.
Did a clean, which removed all the DLL's and then VS2008 complained it couldn't find the references (Duh!!!) and wouldn't rebuild....luckily I had and old version of the dll's and replaced them in the directory AND THEN did a rebuild to replace them...all references are now OK and we're back to normal....good old VS 2008

How to deliver only changes through .Net setup or patch technique

we have our business apps and size is 64 MB. every time add new functionality or change existing one then we rebuild our setup and deliver to client. so this means every time we are delivering 64 MB or more than that to our client.
we have our main win form project and also there many other class library project in our project solution. i am looking for easy way out to deliver only changes to our client.
may be changes could be there in our win form project or could be there in any class library.
so wherever changes made i just only deliver changes through setup and i want just client would install that setup or run any exe file and could see the changes we made in code.
i create setup with VS2005 setup creation option. how suggest me the best option for creating patch like apps which any client just install and get the changes in his apps. give me the best idea to implement in detail. thanks
When using Wix to generate an installer for your project, you can use it to also generate a patch file which will update only changed files.
Visual Studio 2005 setup projects don't really support Patch building and such. It's meant as a rudimentary solution for building installers. Wix, however, is what Microsoft uses internally to build the setup experience for Visual Studio 2012 and other products. There is a very extensive walk-through available here.
Wix does come with a steep learning curve. Would you have been using Visual Studio 2010 or 2012, then you could take advantage of a couple of templates that make it much easier to build a setup for a given type of application. I don't believe these will work with Visual Studio 2005.
This book might also guide you.