Error 1 Program does not contain a static 'Main' method suitable for an entry point.
The scenario in which this arose for me was after importing a WPF project built in VS2008 into VS2010.
Solution
Set the 'build action' property on App.xaml to 'Application Definition'.
Thursday, August 26, 2010
Tuesday, August 24, 2010
To Execute a VSTO from a NetWork Drive
To Add a DLL to the GAC under Windows7
http://www.codeproject.com/KB/winsdk/AddToGAC.aspx
location of gacutil.exe under Windows7
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
location of caspol.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319
http://www.codeproject.com/KB/winsdk/AddToGAC.aspx
location of gacutil.exe under Windows7
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
location of caspol.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319
Sunday, August 22, 2010
Tuesday, August 17, 2010
Windows7 Power Scheme from the Command Line - PowerCFG
open an admin command prompt by right-clicking on the command prompt, which can be found @ (Start > All Programs > Accessories), and selecting 'run as administrator'.
to list existing power schemes and associated GUIDs
powercfg -l
select guid (right-click > mark), copy (enter)
to set the active config
powercfg -s guid
to list existing power schemes and associated GUIDs
powercfg -l
select guid (right-click > mark), copy (enter)
to set the active config
powercfg -s guid
Sunday, August 15, 2010
sqLite
Dr Dobbs
http://www.drdobbs.com/184401773;jsessionid=0COIHAUN55BUJQE1GHOSKH4ATMY32JVN
limitations of sqlite
- http://www.sqlite.org/omitted.html
- http://www.sqlite.org/limits.html
- http://www.sqlite.org/limits.html
http://www.drdobbs.com/184401773;jsessionid=0COIHAUN55BUJQE1GHOSKH4ATMY32JVN
limitations of sqlite
- http://www.sqlite.org/omitted.html
- http://www.sqlite.org/limits.html
- http://www.sqlite.org/limits.html
Friday, August 6, 2010
Data Access - Context based vs Generic
http://ayende.com/Blog/archive/2010/08/06/data-access-is-contextual-a-generic-approach-will-fail.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+AyendeRahien+(Ayende+%40+Rahien)
Agile Dev & Pair Programming
Martin Fowler from Thoughtworks speaks at Univ du SI
http://universite-du-si.com/fr/conferences/6/sessions/909
http://agilemanifesto.org/
http://martinfowler.com/articles/newMethodology.html
http://www.scrum.org/
Ken Schwaber
http://www.youtube.com/watch?v=IyNPeTn8fpo
Agile Modeling
http://www.agilemodeling.com/essays/introductionToAM.htm
http://universite-du-si.com/fr/conferences/6/sessions/909
http://agilemanifesto.org/
http://martinfowler.com/articles/newMethodology.html
http://www.scrum.org/
Ken Schwaber
http://www.youtube.com/watch?v=IyNPeTn8fpo
Agile Modeling
http://www.agilemodeling.com/essays/introductionToAM.htm
Tuesday, August 3, 2010
Debugging Managed Code Called from an UnManaged External EXE
MSDN Bug Report with Problem Description:
Cannot debug .NET 2.0/3.0/3.5 code using F5 in mixed mode from native c++ projects or c# project with 'start external program' set to native .exe.
For pure native c++ projects, when mixed mode debugging is selected in the properties of the startup project and the user presses 'F5', VS 2010 starts debugging for native and .NET 4.0 code - this assumption is not justified, since the user may want to debug native and .NET 2.0 code.
MSDN Fix:
There are two scenarios however that people have been encountering since Visual Studio 2010 released where Visual Studio cannot correctly determine which engine to attach with, and therefore uses the default of 4.0 leaving 2.0/3.0/3.5 applications “un-debuggable”; (1) developing a class library plug-in for a third party application (Excel, Work, AutoCAD, etc), and (2) interop debugging when launching a native .exe project. In both cases the symptoms will be the same, you will be unable to hit breakpoints in your managed code (they will be hollow with a message that “No symbols have been loaded for this document”) as well as being unable to step into the managed code.
As I explained above, the cause of this is the managed application is 3.5 or previous, and the debugger is attached with the 4.0 engine. The best workaround is to add a tag to your application’s *.exe.config file. For example, if I am debugging the application foo.exe I would edit (or create if necessary) the foo.exe.config file in the same directory as foo.exe. I would then add the tag with the correct version of the .NET runtime in the section as shown in the example below. This will let Visual Studio know which version of the .NET runtime you will be running (so if you are developing a class library plug-in for Excel, you would add the tag to the excel.exe.config file).
<!-- sample foo.exe.config -->
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.[version on your machine]" />
</startup>
</configuration>
To determine the correct [version on your machine] look in the “C:\Windows\Microsoft.NET\Framework” directory for the most recent “v2.0.xxxxx” folder.
Cannot debug .NET 2.0/3.0/3.5 code using F5 in mixed mode from native c++ projects or c# project with 'start external program' set to native .exe.
For pure native c++ projects, when mixed mode debugging is selected in the properties of the startup project and the user presses 'F5', VS 2010 starts debugging for native and .NET 4.0 code - this assumption is not justified, since the user may want to debug native and .NET 2.0 code.
MSDN Fix:
There are two scenarios however that people have been encountering since Visual Studio 2010 released where Visual Studio cannot correctly determine which engine to attach with, and therefore uses the default of 4.0 leaving 2.0/3.0/3.5 applications “un-debuggable”; (1) developing a class library plug-in for a third party application (Excel, Work, AutoCAD, etc), and (2) interop debugging when launching a native .exe project. In both cases the symptoms will be the same, you will be unable to hit breakpoints in your managed code (they will be hollow with a message that “No symbols have been loaded for this document”) as well as being unable to step into the managed code.
As I explained above, the cause of this is the managed application is 3.5 or previous, and the debugger is attached with the 4.0 engine. The best workaround is to add a
<!-- sample foo.exe.config -->
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.[version on your machine]" />
</startup>
</configuration>
To determine the correct [version on your machine] look in the “C:\Windows\Microsoft.NET\Framework” directory for the most recent “v2.0.xxxxx” folder.
Subscribe to:
Posts (Atom)