Custom Action VB 8.1

[HippyCraig]

I am working on updating a custom action I have writen to use VB 8.1. If I removed the old refrence to VB7.1 and update it to point to C:\Program Files (x86)\VisBuildPro8\System\VisBuildSrv.dll it causes VS2010 to crash. The solution is ment to target the 2.0 framework, should that be updated to 4.0? Should I be refrencing the Interop.dll directly? Please advise

[HippyCraig]

Here is the error log that gets generated:

Faulting application name: devenv.exe, version: 10.0.40219.1, time stamp: 0x4d5f2a73
Faulting module name: VisBuildSvr.dll_unloaded, version: 0.0.0.0, time stamp: 0x5018920b
Exception code: 0xc0000005
Fault offset: 0x37de81c0
Faulting process id: 0x6cc
Faulting application start time: 0x01cd7579abbb3931
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
Faulting module path: VisBuildSvr.dll
Report Id: 95dd64a5-e16e-11e1-8a13-0800277c2dd2

[kinook]

I wasn't able to reproduce that behavior. Maybe try restarting VS and make sure you have SP1 installed. Are you able to open Samples\User Actions\NETAction\NETAction.sln from the VBP install, which references the v8 interop DLL? One option might be to manually copy the reference from NetAction.csproj after upgrading the project. If you add a reference to VisBuildSvr.dll, it will actually reference the interop DLL (creating if necessary), or you can add the interop DLL reference directly. You should be able to target either .NET 2.0 or 4.0.

[HippyCraig]

The error still occurs not sure what to do here!

In a previouse post, you said that its best to target 2.0, with the 8.1 is it safe to target the 4.0 framework?

See refrence below:
http://www.kinook.com/Forum/showthread.php?t=4987

If 4.0 is supported I can try doing that and see if it handles interop's differntly.

[kinook]

Oh yeah, forgot about that. Nothing has changed in v8.1 regarding custom actions, so 2.0 is probably still the best choice. Are you able to open Samples\User Actions\NETAction\NETAction.sln from the VBP install, which references the v8 interop DLL? Did you try manually copying the VisBuildSvr reference from NetAction.csproj after upgrading the project?

[HippyCraig]

I tried opening that but htere was no solution file just a project file and it upgraded the solution to VS2010. There was an interop DLL in a bin directory already so that refrence was just pointing to that and not the one in the VB 8 install directory. I could just copy the DLL to my project but I wasnt sure if that was approprate.

VS2010 doesnt handle interop DLL well when it comes to deployment packages anyway, it ignors these files. 4.0 doesnt require them the same way that older framworks do.

Just to try it I will upgrade my project to 4.0 to see what that does, I will let you know the results.

Do you know when 4.0 will be officially supported?

[HippyCraig]

Still getting errors, not sure what to try next. I even resorted back to verion 8 but that didnt work either, still get the error from VS2010 below:



Faulting application name: devenv.exe, version: 10.0.40219.1, time stamp: 0x4d5f2a73
Faulting module name: VisBuildSvr.dll_unloaded, version: 0.0.0.0, time stamp: 0x4f8ad884
Exception code: 0xc0000005
Fault offset: 0x37de7090
Faulting process id: 0xb10
Faulting application start time: 0x01cd75939b369cc9
Faulting application path: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
Faulting module path: VisBuildSvr.dll
Report Id: 694cb18a-e187-11e1-9bb6-0800277c2dd2

[kinook]

Right, there is just a .csproj file which will get upgraded if opened in VS2010 (and a .sln file created if saved).

The reference is not path-specific and looks something like

<COMReference Include="VisBuildSvr">
      <Guid>{AD2C35D1-C804-4CCA-8031-236A23427EB0}</Guid>
      <VersionMajor>1</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <Lcid>0</Lcid>
      <WrapperTool>tlbimp</WrapperTool>
 </COMReference>

I believe VS will recreate the interop DLL if needed.

Still need to experiment with .NET framework versions, will bump up on the priority list (don't recall if that limitation was specific to actions that display a UI).

[kinook]

I tested the NETAction and VBNETAction sample actions, and when targeting .NET 2.0, 4.0, and 4.5, the actions built properly in Visual Build 8.1 (64- and 32-bit editions). Running VBP as administrator, are you able to build the User Actions.bld sample, which registers and builds these custom actions?
http://www.kinook.com/VisBuildPro/Ma...rdefaction.htm

Does VS crash when you add the reference, or when doing something else?

[HippyCraig]

The issue occurs when adding the refrence, VS stops working and closes or restarts, sometime it can recover but the refrence isnt there.

I think I found the issue, I removed the refrence closed Visual studio and cleared out all bin directories under the project. I also had to clear out the directories under the obj folder as well, there was a copy of the interop in there as well. Becuase of the way that VS2010 and Framework 2.0 has issues with primary output when you have a deployment package associated with this I had to manually include the interop DLL, this cause it to be checked into TFS. So every time I tried to add a refrence it was finding a copy somewhere in a cache folder. I had to remove the refrence check it in and clear all the directorys listed above again. If you use the 4.0 framwork, it handles interops differently and just imbeses this in the classes dll instead.



With some further testing if I am using a 64 bit OS I can add a refrence to the x64 version of VB but the x86 one cause issues. In the same vaine, if I am on a 32 bit OS, I can add the x86 refrence without issue.



If FW 4 is suppored then the interop can be added to the assebly directly. Below are details to some of the issues I faced with the interop and delpoyments and why I included the interop directly. The setup projects dont detect the interop and include it in the package corretly, even with the copy locally.



http://social.msdn.microsoft.com/For...1-531b8e6ecef0


http://go4answers.webhost4life.com/E...ted-33389.aspx


http://go4answers.webhost4life.com/E...ct-124427.aspx

[kinook]

Originally Posted by HippyCraig

With some further testing if I am using a 64 bit OS I can add a refrence to the x64 version of VB but the x86 one cause issues. In the same vaine, if I am on a 32 bit OS, I can add the x86 refrence without issue.

AFAIK, a COM reference doesn't have a bitness, it's just a type library GUID (see above). The bitness only comes into play when creating a component (a 64-bit process will lookup and create a 64-bit component, and vice versa for 32-bit). What do you mean by a x64/x86 reference, and how would the host OS bitness affect adding a reference?

[HippyCraig]

After removing the issue with the interop DLL that was part of source control this is the behavoir I observed.

I am NOT saying this is dependant on x64 or x86, all I am saying here is that if I had the x64 bit version of VB installed on Win7 x64 then I didnt see the issue, if I used the x86 version of VB on Win7 x64 then I saw VS hang and crash. Not sure if it has to do with VS trying to create the interop DLL or what. I was hoping you could help interpret these results.

[kinook]

That is an odd one. Once the reference has been added, are you able to continue?

[HippyCraig]

I was able to add the refrence as descibed above, I will continue testing. Since you confirmed the new framworks, I will try 4.0 to avoid the source control deployment issue I had.

It will take a few days, but I will post my findings on this thread.

[HippyCraig]

So far so good, I created the new custom action, its targeting the 4.0 frameowok and things are running as expected.

Thanks for the help!