Thank you for taking some time to check my question,
so I need to build corelDraw 6 add-in using VB.NET
so I take 2 ways (1) just try to use VSTA editor ,but didn't work :( I got this error, try to switch .NET version to 3 or 2 but didn't work too, just show the following message >>>>>>>>>>
CorelDRAW
Unable to attach. Check for one of the following.
The application you are trying to debug uses a version of the Microsoft .NET Framework that is not supported by the debugger.
The debugger has made an incorrect assumption about the Microsoft .NET Framework version your application is going to use.
The Microsoft .NET Framework version specified by you for debugging is incorrect.
Please see the Visual Studio .NET debugger documentation for correctly specifying the Microsoft .NET Framework version your application is going to use for debugging.
any advice ...?
(2) I used my VS 2010 and created a class library project ,then used the code in the VSTA and inserted all related references to corelDraw -> build -> all goes well I got my dll file :( but how to make it work as add-in inside corelDraw 6
any advice ...?
Thank you So much,
Ooh I just solve it :)
I copy the dll file which I did using VS2010 in C:\Users\\Documents\Corel\VSTA\CorelDRAW\Addins
re-open corel and it just worked, thank you all
any idea answer about way (1) will be reate too, thank you
Related
Background:
According to the documentation at http://aspnetwebstack.codeplex.com/documentation (under 'Getting and Building the Code' the very first item says:
The easiest way to work with our source is to install Visual Studio 2010 (with SP1).
I am running VS2010 SP1 and have managed to follow all of the instructions to get this source code up and running (on my Win7 64 bit machine). I am have the .NET 4.5 framework installed.
Problem:
During the build (from the command line) as well as from Visual Studio itself, I get the following error:
"The project file 'MY_LOCAL_PATH\src\System.Net.Http.Formatting.NetCore\System.Net.Http.Formatting.NetCore.csproj' cannot be opened. The project type is not supported."
Does anyone know how to get this project to load? All of the others in the Runtime.sln load fine.
UPDATE:
The two project type guids that are in the project file (csproj) are BC8A1FFA-BEE3-4634-8014-F334798102B3 and FAE04EC0-301F-11D3-BF4B-00C04F79EFBC. The first has something to with Metro and the other is C#. I could understand the metro hangup but again the documentation says VS2010 SP1 is fine.
As documented here, the solution now requires VS2012 and Windows 8. I'll update the documentation Wiki accordingly.
I have emailed a few people as well as this post to no avail. Looking more into this and my best guess is that because of the Metro project type I am going to need to get Windows 8 to get this to work. The MVC project does build regardless of this project so I am going to say this is the answer.
Is there any trick/workaround/known "gotcha" regarding Entity Framework 4 and Visual Studio 2012?
I have a project that works and compiles perfectly on my Windows 7, VS 2010, .NET 4 box. Over the weekend I setup a new machine, with Windows 8 Enterprise RTM, and VS 2012 Ultimate RTM. EF design is out of the box, using ObjectContext approach (pre EF 4.1).
I retrieved the working solution from source control, went through conversion process, and get it to build successfully in VS2012 targeting the .NET 4 Framework.
However, when I run the app or debug it, I get "unable to load metadata resource" from the first EF call. Soo ..
Step 1: Work the EF error
Ok, so I use dotPeek to see the assembly, and sure enough when built in VS2012, the EDMX metadata files are not in the assembly.
Step 2: work the missing resources problem
I set metadata processing to "copy to output" and then back to "embed" to force. Nope.
I looked around the MSBUILD files for 4.5 to see if the EntityDeploy targets looked corrupt. Nope.
I did a full repair on VS 2012 to see if something got messed up. Nope.
Set MSBUILD VS version to "11.0" to avoid the 2010 compatibility checks in the csproj. Nope.
Step 3: Delete model, try again using VS 2012 defaults
Ok, I figured I just couldnt make this work. So I deleted the model, and readded as new in VS 2012, which uses EF 5.0 from NuGet, and recontructs using the DbContext approach. Got all this lined up, fixed a few syntax things b/t EF 4.0 and 5.0 and we are building.
Still get same error, still no resources in .DLL
A collegue of mine can build this successful in VS 2012 but on Windows 7 w/o .NET 4.5 installed.
Is there a bug or known issue in .NET 4.5 or MSBUILD 4.5? gotta be missing someting simple.
Figured it out. I don't have a .resources file in this project and it appears CoreCompile in .NET 4.5 is not embedding any of the EF resources files without that being present.
Trying to research is this is expected or new behavior.
Here's a puzzler - something that doesn't work that I assumed would (no surprise there).
We have a library project that is referenced in a few other desktop app projects. The library project is written in VS 2005 (.NET 2.0).
My problem is that some of our apps still live in VS 2005 for the time being (for various reason). I can't seem to reference this library project in VS 2010 without it demanding that I upgrade it to .NET 4, which if I do, then breaks my ability to include it as a reference in my VS 2005 projects.
This type of thing fries my brain. Is there any way I can make this work?
Hmm, that doesn't make a lot of sense. You don't reference a 'library project', you reference the DLL that it produces. Project + Add Reference, Browse tab. There's no known problem with that, within a 95% accuracy guess, mixed mode assemblies have a few hairs.
If you actually try to load a vs2005 project into a vs2010 solution, then yes, it's going to try to convert the project file. And that turns vs2005 catatonic, it doesn't have the time machine to guess what a vs2010 project looks like. Just making a copy of the project directory solves that problem.
Can you change the .NET version back to 3.5 or 2.0 in VS.NET 2010 after it revises the project version to .NET 4.0?
Use a file reference to the built dll, rather than a project reference.
You may also find you need to add an extra bit of compatible-framework info to your manifest file to tell .net to allow your .exe to use .net 4 and .net 2 assemblies alongside each other - if it's not there you'll just get an error on startup. (Sorry, I can't remember the exact details and I'm not at my work machine right now to be able to find them - but if you have problems at runtime, the error message should lead you to the exact solution you need)
Correction: I was thinking of this 'useLegacy' startup setting, which you may need to add to your app.config if you want to use a mixture of .net 2.0 and .net 4.0 assemblies in your application:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
On option, that is a complete PITA, but should work is:
Create a new project file in 2010 that includes everything the 2005 project file has. Just call it MyProject2010.csproj or whatever.
Then, add this project to your 2010 solution.
I'm trying to create an absurdly simple shell extension in C++ using Visual Studio 2010, but I can't even seem to get the examples out there to work as a starting point.
I'm using Windows 7 x64.
I've tried this Visual Studio template, but once I get the template to work in VS2010, I have a host of errors that I'm not sure how to fix.
I've tried The Complete Idiot's Guide to Writing Shell Extensions, and once the demo compiles all the right registry settings etc. are created but no context menu appears.
I've looked at this C# COM Interop example, but I've been left confused as to whether it is safe to use C# thanks to this article*, but it looks like I might be OK if I use .NET 4 because it supports in process side-by-side CLR hosting.
in short: historically two versions of .NET cannot run in the same process, and the way shell extensions work is they inject themselves into a process. So if .NET 3.5 gets injected into a .NET 2 process - bang
So, can I use .NET 4.0 now?
Is there a working, downloadable, VS2010 solution that adds a simple shell extension?
I used to be not so bad with C++ back in the day, but after years of moulding to .NET I'm quite rusty, and as such, fiddling with the details to fix the host of errors I'm getting on the existing examples is proving... fiddly!
I could really do with a clean slate to start with that I can break myself and figure out what I did wrong!
I struggled with this for a while and had limited success with the code project article due to x64 issues and SDK differences.
I recently picked the project back up and started over using the MS all-in-one code sample and I am very pleased. It makes a simple example context menu and x64 works out of the box: http://code.msdn.microsoft.com/windowsdesktop/CppShellExtContextMenuHandl-410a709a
To get it running on your machine:
download the code via the all-in-one sample browser or use the direct link.
Open project in VS under admin rights
switch build config to x64 and build it
Kill all explorer sessions
Locate the new dll and run regsvr32.exe .\CppShellExtContextMenuHandler.dll
open explorer again and right click a .cpp file to see the new menu
remove it by running same command with /u flag
My next step is to get debugging working and I think this may do the trick: msdn
On Windows 7 x64 for a C++ extension you need to build it as an x64 project. In Visual Studio 2010 there is an option on the ATL Wizard to create a shell extension project that provides preview window support, thumbnails and Windows Search support. I recently used this and once built, nothing seemed to happen. However, switching the project configuration to build an x64 dll got it working.
With regards to using .Net - Explorer now launches plugins in a separate sub-process. So loading a shell extension that links to .net 4.0 does not contaminate everything with that version of .net as only the hosting subprocess will actually load that CLR. You can see this using a preview extension as a new process (prevhost) gets launched to contain this.
I got this one working: http://www.codeproject.com/Articles/174369/How-to-Write-Windows-Shell-Extension-with-NET-Lang
Make sure you use the right RegAsm.exe for de/registering it:
32-bit platforms: Compile for x86/Any CPU. Use C:\Windows\Microsoft.NET\Framework\vXYZ\RegAsm.exe.
64-bit platforms: Compile for x64/Any CPU. Use C:\Windows\Microsoft.NET\Framework64\vXYZ\RegAsm.exe.
(XYZ is the version of the .NET Framework you used for compiling.)
Note, however, that Microsoft recommends against using .NET for shell extensions.
The short answer to your 'can I use C#' is no. This is from Microsoft’s Guidance for Implementing In-Process Extensions. "One runtime of particular note is the common language runtime (CLR), also known as managed code or the .NET Framework. Microsoft recommends against writing managed in-process extensions to Windows Explorer or Windows Internet Explorer and does not consider them a supported scenario."
The problem arises because only a single version of .NET can be used in an application and there is no way to enforce that limitation if multiple .NET extensions are in use.
I have installed VS 2010 and want to migrate all code written in VS 2005 to VS 2010.
Please note that we do not have VS 2008, all code are in C# 2.0 and Asp.net 2.0 only.
Can anyone please tell me now what all points need to be considered while migrating.
Update:
I have set target framework to 2.0 for all of my Libraries and web projects. It complies without any error!
However, when site opens in IE (Set to default.aspx), it gives me error as below:
InternalXmlHelper.vb(9) : error BC30560: 'ExtensionAttribute' is
ambiguous in the namespace 'System.Runtime.CompilerServices'.
<Global.System.Runtime.CompilerServices.ExtensionAttribute()> _
Keep all the target framework settings to .NET 2.0. This way, there should be no compilation problem at all.
The changes that you should see are the solution and project files only.
Start with known good solutions in source control (and label—you shouldn't need to go back, but easy to add an extra safety net).
Open each solution in VS2010, allow the conversion wizard to do the conversion.
Resolve any issues.
Honestly, if you're just upgrading VS 2010 you don't really need to consider much. Just keep backups (any real SCM product will do) and you're good. You don't have to upgrade your applications' runtime targets at all if you don't want to.
If you're building with CAS policy, you might run into issues with using MSBuild 4.0 to build you 2.0 applications. If you don't know what I'm talking about, never mind.
My advice is to make sure everyone's "checked in" to your source code provider, and run the conversion wizard and see how it goes.