In VS 2019 the option to initialize projects on the C# Interactive console is missing when targeting .NET Core.
The option is also missing in VS 2017 and there is a related question for VS 2017. However the answer to this question mainly confirms that issue but is not offering a solution.
Does anyone knows if there is a technical limitation and therefore this feature is simply not feasible for .NET Core? Anyone having a good workaround to still initialize the project (with the complete context) manually?
Does anyone knows if there is a technical limitation and therefore
this feature is simply not feasible for .NET Core?
I'm afraid the answer is negative.
So far this option only supports for .net framework, and not for .net core project and .net standard project temporarily.
To get this option available for .net core projects in VS it needs support from both Project-system and Roslyn. For now the Project'system work is done, you can track this issue to follow the progress of the rest work in Roslyn.
Anyone having a good workaround to still initialize the project (with
the complete context) manually?
Go View=>Other Windows=>C# Interactive to get the window,and use #r command(#r "Path/MyDll.dll") to load the assembly manually.For complete context,you also need to manually load all the referenced assemblies.
Actually not a good workaround, it seems there has a way to go before the product team complete the feature, sorry for the inconvenience :-(
Related
I've read some things about .NET Standard and .NET Core, and generally they seem to say something like "This is the new way to do things, and here are the advantages and disadvantages."
What I haven't seen is a good, clear explanation of what was wrong with the status quo, such as .NET Standard and .NET Core were even necessarily. To really judge what I should use these for, it would be helpful to know why they exist at all.
Can someone give a clear (and not necessarily concise!) explanation of (a) what problem .NET Standard and .NET Core are intended to solve, and (b) how they solve it?
.NET Standard is a set of library contracts. Each version includes all the contracts of the previous version - so everything in netstandard1.4 is in netstandard1.5 for example.
.NET Core is an implementation of .NET Standard (and some extra functionality) which runs on Windows, Linux and OSX.
Biggest problems they solve:
Not having a Microsoft-provided/supported toolchain and runtime on Linux/MacOSX. Saying that you could only run .NET-based server code on Windows or Mono was simply untenable.
The Portable Class Library mess with hundreds of different profiles giving partially-overlapping API surfaces to target.
PCLs in particular were very hard to work with for class library authors such as myself. The mess came about because there were multiple efforts to bring a .NET runtime to different devices without enough coordination to provide a coherent API surface to target.
Now multiple vendors can target particular versions of .NET Standard, and anything targeted to that version or higher should work. For example, my Noda Time library targets netstandard1.3. Suppose a new mobile phone vendor comes out with a completely new implementation of .NET, with a completely new kind of application - but says they support netstandard2.0. That's fine - a user of that new platform will still be able to install the Noda Time NuGet package and (implementation bugs aside, of course) they'll be able to use it. I don't need to know that the platform even exists.
I have a requirement where I need to extend or customize the Visual Studio using Visual Studio SDK using C++ or VC++. I have fallen out of luck and have found all the book, blogs and msdn customizing Visual Studio using C#. Need help to share me links and books on customization of VS using C++.
Regards
John.
Help appreciated !!!
Visual Studio 2005 SDK comes with few samples (FigPkg, BscPrj, MyCPrj) demonstrating extending VS using native C++. It's a good way to start.
Newer versions of SDK don't contain this samples. But VSx COM API has not changed too much. Learning internals of different non-C++ projects (MPF, MPF For Projects, VisualD) can also help you better understand how VS-extensions work.
Hai Friends
I having the project in Vb i want to migrate that project in the vb.net.any tool available pls inform me.i have tried a lot.i have not installed the visual basic.with the help of remote server i am running that project.
Quite a few versions of Visual studio have a built-in Upgrade Wizard to help you with converting VB6 to Vb.Net code. I know that VS 2005 Pro has it but I'm not sure what other versions.
Here's an article about how to go about upgrading. And there's even a complete free e-book about it as can be found here.
Aside from the sources Ho1 mentions some of the biggest pitfalls are the lack of control arrays, printing and graphics. The printing can be partly mitigated by the use of Printer Compatibility. You can download the PCL as part of the Visual Basic Power Pack 3.0.
If you have room in your budget I would recommend ArtinSoft. www.artinsoft.com. They have a trial version that you can test out. They have been named Microsoft's preferred VB to .NET upgrade solution provider.
I have trialed artinsoft's upgrade companion.
I have also looked at vbmigration partner.
This is my, very limited, anecdotal experience.
On vbmigration partner they have some sample conversions of projects they found on planat sourcecode.
One is call ezdatabase.
If you run vbmigration partner's conversion it will crash if you click the connect/disconnect button more than twice.
On the vb6 version you can click this all day without crashing.
This project is small enough to put through the artinsoft trial of vbuc in its entirety, so i did that.
However after i converted it, there seemed to be a lot of compile errors.
It's not a fair comparison as obviously vb migration partner had lots of opportunity to perfect it before putting the converted code on their website. and yet it was easy to crash.
However I was also disappointed with artinsoft's tool as this was just a small (few hundred lines) crud application and yet there were a lot of compile errors.
Make of this what you will. I would like to hear of others' experiences.
EDIT : On the other hand if this is a true test of the relative capabilities of vb migration partner and artinsoft vbuc then vb migration arner is clearly the winner in this example
95% of my time I program ASP.NET (MVC) web sites.
Should I care about MSBuild?
We use MSBuild with CruiseControl.Net to manage the builds of most of our big ASP.NET projects. For every commit of one member of the team, a build is launched. It helps us detect
quickely incompatibilities before moving a feature to "staging" or "production".
I think it is really usefull when working with a team on the same ASP.NET project or if you are working alone on a big project.
That depends on your development environment.
If you have other folks that do deployment of your systems, and they take care of the build and deployment environment, then MSBuild probably won't be necessary for your work.
On the other hand, if you need to configure the build script to understand special situations that your code comes up with, then you will definitely need to understand MSBuild scripts.
Even for a one-man shop, it's a useful tool to know, especially if you are configuring a continuous integration server like Hudson.
No. Until you have to.
Its not absolutely necessary to know MS Build, but it is useful to know.
It might not be needed for all kind of projects, but it is extremely useful when you are working on a huge code base with automated custom build solution/ nightly build/developer builds so on and so forth.
It's unlikely, unless you choose to use it, or you start to make use of Team Foundation Server's Team Build.
Your development processes need to get to a certain complexity before automated builds really deliver their true value and/or if you find need for automatic deployment (including database changes if applicable).
The coming Visual Studio 2010 is going to make it far easier to use, but for now it retains a fairly steep learning curve which you can avoid by using alternatives, or commercial products (e.g. Visual Build Pro, Final Builder etc).
The nice thing is that it is part of the .Net framework, so it's already available as long as you have the framework installed (which it probably is).
So, in short, not really. It's something very useful and powerful though, setting up deployments using MSBuild can be very, very useful.
What should a developer know about MsBuild?
Every developer should know it exists and it's basic capabilities. If know it exists you won't duplicate its features and will know what it can do for you, when you need it.
Minimum:
As an exercise, build your project through the command line: msbuild myproj.sln
Know the role of continuous integration
A little more than minimum:
Hack your csproj (or vbproj) with a message task, so it outputs something during clean.
All done. When you need to know more, you'll figure it out.
Has anyone built a website with IronPython and ASP.NET. What were your experiences and is the combination ready for prime-time?
The current version of ASP.NET integration for IronPython is not very up-to-date and is more of a "proof-of-concept." I don't think I'd build a production website based on it.
Edit:: I have a very high level of expectation for how things like this should work, and might setting the bar a little high. Maybe you should take what's in "ASP.NET Futures", write a test application for it and see how it works for you. If you're successful, I'd like to hear about it. Otherwise, I think there should be a newer CTP of this in the next six months.
(I'm a developer on IronPython and IronRuby.)
Edit 2: Since I originally posted this, a newer version has been released.
Check out the Dynamic Languages in ASP.NET page on Codeplex. This has the newest IronPython bits. It doesn't give you any Visual Studio integration, other than the sample website project, but that's coming.
Keep a look out for ASP.NET MVC
The IronRuby guys have got some internal builds of MVC to work with IronRuby, and IronPython 2 and IronRuby have a lot of code in common with the DLR.
I'm not sure if they'll support IronPython/IronRuby when MVC is released, but it's definitely worth keeping your eye on anyway - The old ASP.NET forms-based development model is old, busted, and the sooner it goes away the better.